This code is licensed under the LGPL, like the other XBList bits I’ve released. As usual, I would appreciate it if whoever uses this code would email me to let me know how they’re using it, just for my own amusement. You can download the control right here.

Hopefully this component will continue to be useful to other developers, and they’ll let me know if they’re using it in their projects, since it’s just so much more fun to release stuff for free when you get to see it in action.

I noticed a few things from the conference that I wanted to write down before I forgot. The first is that even in Java-land, scripting languages are hot. Lots of people were talking about JRuby, Groovy, JavaScript, JavaFX Script, and more. JRuby in particular was getting a lot of excitement from everyone who’s been hearing for the last couple years about how cool Ruby on Rails is. I’ve seen a lot of Rails demonstrations and they’ve failed to impress me but the Ruby language itself is very appealing, especially to someone like myself who mainly scripts in Perl or JavaScript. I’ve definitely been convinced to use Ruby for my next personal web app project, and the combination JRuby’s speed and native access to Java code will make me feel a lot better about it.

There were a lot of talks about static analysis tools, and FindBugs in particular. I’ve been using FindBugs on my Java code (and FxCop for my .NET code) for quite a while, but a few of the presentations gave me a much better idea of how powerful static code analysis can be. One of the best ideas is using special annotations that more clearly document the intended behavior of your code. Not only does this serve as additional documentation, it helps you design your classes better and helps out your code analysis tools. One of the first things I did when I got back was grab the latest FindBugs release and start sprinkling those magic annotations all over my code, and from now on I’ll be writing them in whenever I write new code.

I also got more in-depth exposure to the REST philosophy, which I had heard a lot about but not really thought about too much. I really like the idea, but until the tools get to the point where I can write up some sort of service description and generate client code like I can do with WSDL, I’m going to hang back a bit. Maybe WADL will catch on. I also got a better explanation of OpenID than I had gotten previously, and I’m really impressed. I like that it’s so simple, and that it can still integrate with technologies like CardSpace in a way that adds value to both sides. I searched for an open implementation of an OpenID provider that uses CardSpace, but it doesn’t look like any exist yet.

Another, less explicit theme at the conference was that the Java community has noticed the great design of C# and the .NET framework and are trying to fit some of that back into Java. I’ve always felt that C# was “Java done right”, and the number of JSRs (Java Specification Requests) that I saw for C#/.NET features is a testament to that. JavaSE 5 already added annotations (attributes), generics, foreach, enums, variable length arguments lists, and autoboxing, all features from C# 1.0 or 2.0. The stuff that’s being discussed for JavaSE 7 and beyond includes “superpackages” that look a lot like assemblies, continuations, a “using” statement, generics that don’t use type erasure, indexers, and switching on strings. I think this is great – C# made a lot of great improvements that were no doubt based at least in part on experience with Java, so it’s natural for Java to get back some of that. I didn’t see much talk of any of the C# 3.0 features like LINQ, object and list initializers, extension methods, etc. I did see some talk about incorporating lambda expressions, though, which would be pretty nice.

Despite the fact that the Java language has some catching up to do, one glaring advantage of Java over .NET became apparent to me while I was there. I’m not talking about the platform-independence advantage, though that is certainly there – I don’t think I could imagine building a large, scalable distributed service with Windows machines. No, what I’m talking about is the community. That’s not to put down the large and active .NET community, it’s just that the Java community is huge. And especially through open source, there’s just a lot more going on. I feel like a large part of this is that Sun and other Java leaders have been willing to incorporate the community’s best products into the standard toolset. Products like ant, Eclipse, Spring, JUnit, and even JRuby are accepted tools. Meanwhile on the .NET side, you’re basically taking whatever Microsoft gives you. And while that can usually be good, Microsoft runs the risk of ignoring the direction people are actually heading in.

In the end, I left the conference with much the same opinion of Java that I had in the beginning. Java is a tool, and a good tool, but not a particularly exciting tool. It does have some exciting features (I love JMX), and after my week in the Moscone Center, I feel like I can be more competent at creating Java-based software. Maybe I just haven’t worked on the right Java projects. I hope as my experience with the platform grows, I’ll be able to contribute more, either through this blog or through open-source projects. And who knows, maybe one day I’ll really feel like a Java Guy.

In .NET and Windows Forms, the default font for controls is actually Microsoft Sans Serif, not the operating system's default dialog font! Kevin Dente explains this on his blog. This is not the only time Microsoft's dropped the ball on this - if you go through some dialogs in Vista you'll see that many of them use Tahoma or even Microsoft Sans Serif instead of Segoe UI. This is pretty funny, especially when Rule #1 of the Top Rules for the Windows Vista User Experience is "Use the Aero Theme and System Font (Segoe UI)". Mitch Kaplan offers up a pretty good explanation for why getting it all right is very hard, but having a mix of old and new fonts still looks shoddy.

I don't want my apps to look shoddy. Embarrassingly enough, I've been hardcoding Tahoma in all my apps to get the more "modern" XP look. Now that Vista's on the scene, it's clear that I want to select the correct default font for whichever OS my app is running on. As Kevin points out, Control.DefaultFont is no help here - it's what's driving Windows Forms' default choice of Microsoft Sans Serif in the first place. After some digging I found this Visual Studio feedback ticket (sign in required), where the Visual Studio guys explain that, while they couldn't fix the default, they did create a SystemFonts class to help out. They recommend putting this code in your Form's constructor:

Unfortunately, this doesn't work in a number of ways. The first is that on Vista, SystemFonts.DialogFont is... Tahoma! Closer, but not quite right yet. If you pop open SystemFonts in Reflector, you'll see that the DialogFont property just does some simple platform-detection, and then just hardcodes Tahoma. This worked when it was just 2000/XP vs. 9x, but Vista throws it for a total loop. Fortunately the fix is easy - use SystemFonts.MessageBoxFont instead. This one seems to always return the correct default dialog font.

However, I ran into one more problem. If I set the default font on the Form, like the code above does, I get weird, bloated controls:

Fortunately I've got a solution for that one too. Instead of setting the font on the Form and letting it inherit, just loop through the Controls property, and individually set the right font on each control:

Now I get a more familiar-looking dialog:

I could always make a subclass of Form to do this for me, but I'm OK with copying it into each new form. With this code, all my controls come up with the pretty new Segoe UI font in Windows Vista, and Tahoma in XP.