Mustang: the little things
I'm taking a brief hiatus from my series of blogs on href="http://weblogs.java.net/blog/zixle/archive/2006/01/architecting_ap_1.html">application architecture to join in the mustang blog carnival extravaganza that is celebrating the beta release of mustang. The bulk of the major features have already been covered. Chet and myself have covered true double buffering, Shannon has covered the dnd work, SwingWorker was covered in an article, table's sorting and filtering API was discussed as well. I've even covered some of the smaller stuff, like the action improvements. So, what to talk about?
After struggling with what to cover, I realized that some times it's not just the big things that make a release matter, but a culmination of both the big things and the little things. So, in this blog I'll cover the little bugs and features. The things that by themselves aren't that big, but undoubtedly make the release that much better.
Anyone that has seriously used ButtonGroup undoubtedly stumbled over
the inability to clear the selection of the group. For example,
lets say you have two toggle buttons in a button group and you
need to clear the selection to an initial state. Previously
there was no way to do this! Sure, there are some ugly
workarounds, but thankfully we've addressed this problem now. In
mustang we've added the method clearSelection to ButtonGroup. Funny enough this is the oldest bug we've fixed for Swing in mustang.
One of Swing's most voted on bugs is support for fully justified text
in Swing's text components. What's doubly bad about this feature
is that we've always had API that implies it would work, but it
never had. Well, thankfully it now does. Here's a screen shot of
Stylepad in mustang with fully justified text:
YIKES! I know, it turns out we justified the last line of the text which obviously doesn't look good. Thankfully this bug will be fixed before the final release of mustang. Here's a screenshot with the fix:
Another long time sore point is the inability to enforce a minimum size for Windows. Being a long time NeXT/Apple user I've always thought it a good idea to enforce a minimum window size. That doesn't appear to be too common on Windows boxs though. None-the-less the API now works and you can set a minimum size. Here's an internal app that can't enforce a minimum size:
And that same app with mustang when it could enforce a minimum size:
Painting offscreen components
Getting into the more niche arena, Swing's painting code has always
ignored painting child components if the Component is not
contained in a Window or an Applet. Why would you ever do this?
Perhaps you want to render a JComponent, and it's children, to
an image. This came up a number of times on the forum. Finally
it's fixed! I know, a bit obscure but none-the-less
interesting. See 6215148 for details.
The last thing I'll mention is certainly not a small change. Following
the JTable printing support we added in 1.5 we've now made it
trivial to print text component. JTextComponent now has a print method that allows you to specify various attributes of the print job, such as header, footer... This means it's now trivial to print a text component and have the output reformatted for the page, just like a user would expect!
So anyway, if you haven't yet tried mustang I highly recommend you
give it a whirl. As an incentive we href="http://weblogs.java.net/blog/robogeek/archive/2006/01/announcing_the.html">announced a free t-shirt for any regressions that are found as well as the chance at winning an Ultra 20, sadly this offer isn't availble to Sun engineers;)
Next time around, more application architure.