Joshua Marinacci's Blog

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.

Java 6 contains lots of great new features, from the new Desktop API, to multiple gradient paints, to a built in Javascript interpreter. But I'm not here to talk about features either.

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 Fixed Delivered, Closed, or 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!

Comments

• That looks awesome, Joshua. Although most of the fixes are subtle, the overall effect is cumulative, and significant! Great work.

  Posted by: javalori on August 18, 2006 at 08:24 AM

• I second that. Love the new L&F. Thanks for all your hard work on constantly improving Swing!

  Posted by: jattardi on August 18, 2006 at 08:33 AM

• yes, subtle is right. I wonder if he fixed the bug where something was off by one pixel... :D

  leouser

  Posted by: leouser on August 18, 2006 at 08:46 AM

• Great work, Josh! Makes all the difference for Java apps on the desktop.

  Posted by: jaredmac on August 18, 2006 at 09:09 AM

• Which one of the eight different 'off by one pixel' bugs are you talking about? ;)

  Posted by: joshy on August 18, 2006 at 09:18 AM

• heh, hilarious. I didn't know there was 8 of them. Ive just know Ive seen titles like "off by one pixel". And I always wonder how the heck did the notice that... maybe it is obvious.

  leouser

  Posted by: leouser on August 18, 2006 at 09:28 AM

• Josh,Your stamina is awesome.I would have thrown up my hands and run screaming from the building long ago.-JohnR

  Posted by: johnreynolds on August 18, 2006 at 09:32 AM

• Thanks guys. It's true that these are often hard to find bugs. Most of them have been reported by developers though, not discovered by me. I also looked through the very detailed bug list in the winlaf project to see what we still need to cover. There's more to do of course, but I think we've accomplished a great deal with Java 6.

  Posted by: joshy on August 18, 2006 at 10:23 AM

• Back porting is golden. For the guys on 1.5 who wont see 1.6 for a while, thanks a million :)

  Posted by: ilazarte on August 18, 2006 at 10:44 AM

• All these little single pixel adjustments are welcome and I thank the dev teams for them. But they don't matter quite as much as things like Bug #6187163 which have a real effect on the usability of the UI. That would it be like if your Java 6 screen shot above shows "Com..." instead of "Combo", which is actually what most of my Java 6 comboboxes look like. The effort is much appreciated... but let's try to avoid making many barely noticable improvements only to introduce a glaring bug that ruins existing UIs.

  Posted by: swpalmer on August 18, 2006 at 11:48 AM

• This bug in Java 6 has already been fixed and should be in the latest public builds (or coming in a week or two). I thought it was only against Java 6, though. Did this go against Java 5 instead?

  Posted by: joshy on August 18, 2006 at 02:09 PM

• Guess what? It's fixed in today's build :), or rather Bug #6439971 is. Yes it is only against Java 6. I think it happened in one Java 5 build but didn't last for long. #6187163 probably should be closed, I suspect 6439971 is a duplicate, but I haven't tested yet... I've just been reading the release notes.
  JDK6 b96 is a "big one" with lots of Swing fixes in particular. Great work!

  Posted by: swpalmer on August 18, 2006 at 07:08 PM

• You know what would make my day? A commitment to fix JFileChooser in JDK 7. It is one area of the Windows look and feel that the users really notice as not working like the the "real thing". The sorting fix in the detailed view helps a LOT. Better support for the context menu would be great. Simple things like fixing the buttons to select the view type would be nice. (And backporting all those fixes to JDK 6 at some point would be sweet.)

  Posted by: swpalmer on August 18, 2006 at 09:23 PM

• I don't work on the JFileChooser so I can't say what will happen, but I do know that resolving the long term issues of FileDialog and JFileChooser is on our requsted list for JDK 7. We don't have a final feature list for JDK 7 yet so I don't know if it will be done (or when), but it was on our request list.

  Posted by: joshy on August 18, 2006 at 09:28 PM

• Great job, Josh :) The Swing team are *awesome* for having done such an outstanding job improving Windows L&F fidelity (so much so that I spend no time on WinLAF these days, in the knowledge that it's rapidly becoming very obsolete :) )

  About the text field popups (a slight bugbear of mine): did you guys consider some kind of optional mechanism (off by default for compatibility) that would allow application developers to set some look and feel-level property to say, I want all my JTextFields to have the standard windows popup in their componentPopupMenu property by default?

  Anyway, once again: fantastic job :)

  Brian

  Posted by: brianduff on August 19, 2006 at 02:53 AM

• Yep Josh you've done a fantastic job and your work is much appreciated. Although I build my app for 5, I strongly encourage my users to to use 6 just for the L&F alone (well, and the LCD text and Java2D performance). Fidelity IS important. I personally am not worried about things like default context menus or JTextArea font, since those things are trivial to implement ourselves. Although a pet peeve of mine is the menu for JInternalFrames needs icons for Restore, Minimise, Maximise, and Close. Surely you have time to squeeze that in? I'm also not satisified with how menus look in general. But thats about it really. Oh one more (a biggie), I'd like to see the button focus-rect tabbing behaviour implemented in Dolp... err... 7. That's my wish list!

  Posted by: benloud on August 19, 2006 at 09:05 AM

• benloud and brianduff: I'm afraid there won't be anymore squeezing of fixes in. We've be in critical-bugs-only mode for a month or so and as of last week everything is pretty well locked down (I got one Vista bug in after that, for example). However we can always get these things into an update release. As always, contributions are welcome.

  On the context menu: we had considered adding a property to selectively enable the feature but we decided to wait until Java 7 when we should have a full compatibility API. Given that this is a feature developer can easily add with 3rd party solutions it seemed like the best answer. It's first on my list for Java 7, though!
  

  Posted by: joshy on August 19, 2006 at 02:00 PM

• Josh, the sum of all those small improvements make a huge difference.

  But did you notice that the foreground color of disabled JRadioButton and JComboBox is wrong in reccent builds? The text it displayed in black while it should be grey. Quite an important bug (and a regression) and probably easy to fix, so I hope this one will get fixed for Mustang final.

  Posted by: jansan on August 20, 2006 at 03:02 AM

• brianduff - the context menu on any / all text components is available in Substance 3.0 and any other look-and-feel that will decide to use the laf-widget layer with as simple a line as UIManager.put(LafWidget.TEXT_EDIT_CONTEXT_MENU, Boolean.TRUE) for all text components, or setting the matching client property on a single text component.

  Posted by: kirillcool on August 21, 2006 at 03:30 PM

This work is licensed under a Creative Commons License.