Chet Haase's Blog

August 2005 Archives

Mustang, Swing, and NetBeans on Windows Vista: Looking Good!

I've been playing around with the Windows Vista Beta1 release lately, seeing how we're doing for compatibility and native look and feel. There are some minor issues that need to be fixed, but in general we're looking great. It's a nice confirmation of the changes we made in Mustang to use the uxtheme APIs in Windows to render our widgets for the Windows look & feel; we didn't need to make any changes to our code to make our widgets look correct on Vista versus XP.

Today, I installed the latest daily build of NetBeans 4.2 to see how it looked. You can see the results by clicking on this screenshot:

If you look closely, you can see that some of the text areas in the latest NetBeans bits are taking advantage of the LCD Text support we've implemented in Mustang.

By request, here are some screenshots of SwingSet2 on Mustang on Vista, running with the native look and feel; this should give you a sense of how native the controls look so far (click on the thumbnails to see a larger picture):

There are some issues to be resolved, such as the rectangular windows decorations (JInternalFrame has square buttons) and some mouseover effects that we are not yet capturing. But things are looking pretty good in general.

And remember that you can always download the latest Mustang snapshot to try out these nifty experiments yourself.

Caveats for the images above:

• Some browsers have awful support for PNG images, so if the pixels look really distorted in your browser you may try downloading the image and viewing it in an image viewing app instead. I had good luck with Firefox 1.0.7.
• The LCD text looks good on the particular display on which I took the snapshot. If you are not viewing this on an LCD display, or if your display has a very different configuration than mine, you will get different visual quality. The app running on your system would look good, but a screenshot of the app running on my system is a different thing entirely....

Persistent Questions

As Kermit once almost said, "it's not easy being free."

Having a free and popular download has its advantages. Developers like the platform, they grab updates, they post bugs, they participate in forums, they come to conferences, they read blogs (I hope), ....

But being free and popular also has a downside (beyond the whole "revenue" thing): we don't necessarily know what parts of our libraries people are actually using.

Sure, we know the big-ticket items. We know the features that are most requested, we know the areas that get heavily used because of constant bug reports and JDC votes, we know the industry-trendy areas of the platform that we need to keep working on, etc.

But what's harder to gauge is the use of the more subtle parts of the platform, APIs that developers probably use a little of for specific pieces of functionality, but that don't get much public fanfare because they're just basic plumbing. I mean, I might mention to someone that I got a new granite countertop in the kitchen, but I probably wouldn't bother talking about having installed a brand new drain in the sink. It's just not very exciting.

And what makes this particularly difficult to gauge in a platform as broad and huge as Java is that there are often many different ways of accomplishing the same task.

Take persistent storage for application preferences, for example; I'm talking about the "my app reads this stuff every time it starts" data, not the data stored with particular documents that may not be read at startup. There are so many ways of accomplishing this rudimentary task that I probably can't think of a majority of them. There's the Preferences API, there's the Properties API, there's roll-your-own file approaches, there's lots of different XML-based approaches, ... and on it goes.

Which ones are developers actually using? Any of these? Some I haven't mentioned? None of the above? All of the above? The sad truth is I don't know. It comes back to the problem I stated above; people download our stuff, write the applications, get it to work, ship it ... and we don't know what they decided to use (unless problems crop up; then we hear about it. A lot).

So now we get to the crux of it, the meat in the puff pastry, the cherry in the sundae, the pebble in the shoe:

• What do you use to persist your application data?

At this point, or maybe way back at the beginning, you might ask "Why does he care? Isn't he a graphics guy?". A fair question and one which, in recent weeks, has been much on my mind. Yes, this is pretty far outside the graphics realm. But one of the hats I wear here has a label that says "member of the startup performance team", and it's in this capacity that I care.

XML is often associated with server-side or web-related development. Its angle brackets are spewed all over the place in those realms. In desktop apps, it may be used as a file format, but there tend to be much bigger issues in the desktop space, so XML doesn't get a lot of press for desktop apps.

Because of this history, performance of XML-related technologies has been more server-side focused: how fast can your business logic crank on some DOM thingie? Issues of startup, like how fast can you parse that XML file, are pretty irrelevant in this space; if it only happens once for a long-running server application, it's not worth worrying about.

But if desktop apps are using these technologies to persist data that's read at startup, then it becomes an interesting area in terms of desktop app startup performance. Server apps may stay up for days or weeks at a time, but desktop apps are lucky if they run all day. In this context, the speed at which those apps start up becomes much more crucial. And if there are common things that all applications are doing at startup time, then we'd better make sure those things are performing up to snuff.

So, how about it:
Can you tell me what to tune here? Should I be benchmarking Preferences? Or Properties? Or one (or all) of the several XML-related APIs? Or are people just rolling their own and we should just make sure file IO is fast enough to handle it? Or is this simply not an issue and I can return to thinking about pixel performance?

Lay down a quick comment below if you have any tips here for me. Sure, it's anecdotal evidence, but anything helps.

This work is licensed under a Creative Commons License.