The Big One
So you have probably wondered where I've been. It has been quite some time since my last post and I have been very lax in talking about what's going on. Well, the big news is that we are almost done with Java 6. Not really, of course, since there still emergency fixes that could go in, but we've hit our final build of main development. This means that my work is mostly complete for Java 6 and I can start working on the update releases and Java 7. However, scheduling and builds is not what I'm here to talk to you about.
I'm going to warn you right now that this post is a bit goofy. I'm exhausted from the L&F work but excited to talk about it. If dire goofiness offends, you may conveniently press the back button now. We'll wait.
I'm actually here to talk to you about a set of bugs. Bugs so great and awesome that the fixing of them is itself a feature. Yes. That's right. Unh-huh. I'm going to talk to you about the Windows Look and Feel. Solid!
Some Background on the Windows Look and Feel
For those of you who don't know, there is this operating system called Windows, the most recent incarnation being called Windows XP and a forth-with-coming version known by the name: Vista. ('cause it's big, right?) Despite the fact that Java is cross platform, something like 90% of desktop Java users are on Windows. (perhaps because 95% of computers are Windows PC? Hmmm.) Now this matters a great deal because we provide a Windows native look and feel for Swing. Some will debate the merits of having native look and feels. "No one cares about apps looking native". There is some truth to this argument, but I think that no one will deny the fact that if we are going to have a native look and feel then it had better be a damn good one! Thus fidelity is an important issue. Every time someone says they went with .NET, Visual C++, or SWT for their desktop app instead of Swing/Java they almost always give the same two reasons: speed and Windows L&F fidelity. So clearly we have a big job to do. Speed is pretty good with Java 5, so that just leaves one thing.
In the past we duplicated Windows drawing code in Java. We were not getting any resources from the OS other than a list of system colors. This worked fine in the Win95-Win2k era, but with XP the standard widget themes became more complicated. XP has a themeing API within it that lets users choose from one of three theme variations. This was not a public API but developers like the guys who make StyleXP reverse engineered it. Soon the community started hacking out new themes by the dozen. (and I want you to know that I've tested many of them, even the super-ultra-ugly ones, but more on that later). Clearly we couldn't duplicate every theme in the world. Even just duplicating XP's built in themes would be a tough job. Thus in an earlier version of Java (1.4.2 I think) we introduced changes to the Windows Look and Feel which would parse the XML theme files and extract theme information. This worked. For a while.
As the release of Vista came near (then Longhorn) we realized that the parseable XML theme files were going away, to be replaced with binary blobs. Fortunately Microsoft has decided to officially support themeing via their UXTheme API, an API which exists on both XP and Vista. Sweet! Early in the Java 6 development cycle Leif Samuelsson rewrote a good portion of the Windows Look and Feel to use this new API, giving us full access to the underlying themeing engine. This is really the only way to properly support theming on Windows and it ensures that any theme, not just XP's built in Luna themes, will work. We still don't officially support third party themes, but we do our best to make sure they work. (Especially the ugly ones!) In fact, many of the bugs I fixed for the standard XP themes also fixed bugs with certain extra themes as well. A win-win situation.
So where are we now:
First, a caveat. I cannot claim credit for all of the great work done here. I started working on the Windows Look and Feel in March of 2005, around the build 30 timeframe. Leif Samuelsson did all of the initial work and I've received lots of help from Igor Kushirskiy and Richard Bair. Their work has been invaluable.
Second. Some of the bugs we've fixed or are on the process of fixing are Vista specific. I won't cover those here since Igor has done most of that work. Maybe we can convince him to do some blogs about it once he's done. (How about it Igor?! :)
Now on with the show.
First: the bad news.
We didn't fix everything. There are many, many bugs to be fixed and not enough time to fix them all. In a perfect world we wouldn't ship Java 6 until everything was perfect, but the real world needs shipping products so some fixes were deferred to Java 7 or later. If your personal favorite bug wasn't fixed please rest assured that we fixed other, higher priority bugs instead. We'll get to yours as soon as we can. And if you really feel passionate about it please consider submitting a bug fix through the JDK project. At this point fixes won't get into Java 6, but they could go into an update release or Java 7.
Some things weren't fixed even though we had the time. The reason is backwards compatibility. It is very, very, very important that an existing application won't break when the user updates their version of Java. Some bugs couldn't be fixed without breaking backward compatibility so we didn't implement those. In the future (Java 7 most likely) we will have a compatibility API that allows developers to choose between old and new behavior, but for now we just have to live with these bugs. The most widely known is the context menu for text fields. This is the menu that has
cut/copy/paste actions in it. We could have easily added this but it would have interfered with existing applications that already have menus or other mouse listeners attached to the text fields. For this reason we left it out. Some of these fixes are really simple things, like making the font of
JTextArea not be fixed width, but again we couldn't do it. Some applications use text areas as code editors and count on the font being fixed width. Since these are bugs that developers can address using their own code (or the great winlaf project) we decided to hold off on them.
Okay, so that's the bad news. What about the good news.
Well, we fixed a lot of bugs. A quick query reveals that I have 80 bugs in the
Fix Available state. Wow! I didn't realize it was that many. Sure, some of them are invalid bugs or things that were fixed by other patches, but still. That's a lot of bugs! And that's just mine. It doesn't count what other Swing developers have done. Rawk!
The other good news is that we are still working on new fixes. There's more good stuff to come. Some fixes may go into update releases to Java 6, so keep an eye out. And, as always, submit your fixes to the JDK project.
Okay, so that's the good news. But what about some GREAT news?!
The great news is that a good portion of these Windows Look and Feel fixes have been backported to the recently released Java 5 update 8, and more should be coming in the future. These fixes are risky because there is always the danger of a regression (and in fact one has already been reported and a fix is in progress), so please test these heavily and give us feedback. Regressions are always a top priority and we'll do our best to fix'em.
Great, Great, fine! Enought with the chit chat. How about some pictures! Where are the bugs! Show me!
As I mentioned, I've closed 80 bugs over the last year and a half. I'm not going to cover all of them but I will cover a lot. I'm just not going to cover them right now. Over the next couple of weeks I will post a series of blogs discussing the new fixes along with screenshots for comparison. Maybe this is really only interesting to a pixel pusher like me, but it's my blog and I can do what I want to. So there!
To whet your appetite here's a screenshot from my testing app that shows build 10 (figure 1, almost 2 years old now) versus build 94 (figure 2, which I think is public now). Note that all textbox-ish components have the same height, the fonts are the same, and the password field has bullets now.
Figure 1: Java 6, build 10
Figure 2: Java 6, build 94
See you all next week!