Chet Haase's Blog

June 2005 Archives

JavaOne Desktop Sessions

I don't know about you, but I find conference program guides and websites somewhat difficult to use. There are just so many sessions in so many different areas that it's tough to wade through the universe of possibilities and figure out where I'm actually supposed to be at any given time (besides looking for a good cup o' coffee, of course).

To that end, we wanted to give you a condensed guide to the Desktop sessions at the conference. For those that have PDA's that can import .vcs files (my Pilot can, for one), here's a link to the desktop sessions that you can just import and go with. For everyone else, here's a table of all of the Desktop sessions, listed chronologically.

By the way, we will also have a flyer at the pods with all relevant Desktop information on it; these were handy last year for quickly finding the session/event you needed. Stop by the desktop pods and grab one before you start your crazy week.

And here are the BOFs:

What are my favorites? Well, apart from the ones I'm speaking in (Tuesday's "Advanced 2D" talk, Thursday's "GUI Puzzlers" talk, and Tuesday's 2D BOF), I have to say they're all good. Every one of them.

Of course, since I helped choose the topics and sessions, what would you expect me to say? But I think we did a pretty good job with the Desktop track this year; we made a serious effort to recruite ideas, sessions, and speakers from outside of Sun, to get both a balanced view of Java Desktop development as well as talks that would interest the community. Let's see how you feel about it after next week, but I'm feeling very good about it. Although I should really try to finish my slides and demos soon...

Mmmmmm VM.....

Before we start, please check out Grzegorz Czajkowski's blog. Greg talks a bit about the technology and has links to related sites (including, of course, the project page for MVM. Note, however that you will need the JDK Researcher role in order to view the project). I'll wait here; you go ahead and check it out now.

All done? You read the blog, saw the project, formed some opinions? All right, then; let's go!

It seems like MVM is one of the hair-triggers for Java developers. Whenever I hear it mentioned, the comments are along the lines of "We need MVM!", or "Why isn't it in the platform yet?", or "It'll be in the next release for sure." Whenever we query developers about what they'd like to see, the answer is usually "MVM!" How do we improve startup performance? "MVM!" How do we improve application footprint? "MVM!" What do you think of the new graphics acceleration features? "MVM!" There are forums devoted the subject, rants on popular developer sites, and generally entertaining and highly-charged discussions with lots of exclamation points and death threats.

So given all of the excitement around MVM, why isn't it in the platform yet? Why aren't we planning on putting it there, at least in Mustang? What are we thinking? I mean, obviously everyone wants it, so why don't we listen to our community and just put it there?

First of all, let's take a little step back and think about what MVM is. In particular, I'll focus on the aspects about MVM that caught everyone's attention (including mine) initially; startup and footprint benefits. As Greg says in his blog, there's a lot more exciting stuff in there, especially the Application Isolation API. But I wanted to specifically address the performance aspects of MVM and what they mean (and don't mean) to typical desktop applications.

Basically, MVM provides a way to launch separate Java applications in the same virtual machine. Currently, separate Java applications all run in their own process, completely independent of one another. There is some very simple sharing happening under the hood in terms of shared libraries (specifically, the DLL's on Windows, the .so's on Unix, and some of the Java classfile data on all platforms). But other that this basic OS-level sharing, all of the processes are completely independent.

This process independence means that every new Java instance fires up its own copy of the executable, loads in its own classes, creates its own heap, and suffers its own startup performance hit (whatever it is). There is significant startup benefit from being the second Java application in general, but this is due to the disk caching happening at the operating system level, not due to any sharing between our Java processes.

Two things that bug some desktop Java users (and, by the transitive property of software usage, the developers of Java applications) have complained about over the years are the time that applications take to startup, and the RAM footprint that these applications consume on the machine. Startup time has actually gotten much better over time, through a combination of Class Data Sharing (implemented in Tiger, a nifty way of preloading all of the core classes that desktop apps usually need), various performance tweaks, and the inevitable speedup of processors, disks, and operating systems. Footprint continues to be an issue, although with standard PC memory configurations, this is less of an issue now just because the footprint occupies a lesser proportion of a machine's RAM when that machine comes with so much to begin with. But both are important issues that we should (and do) continue to work on.

Along comes MVM, which has this nifty property of sharing process overhead. In particular:

• Startup: Each new Java application has a nearly free startup of the core VM and classes that are already loaded. Obviously, an application would still take time to load in their own classes, but the stuff that was already loaded by other MVM apps would come for free.
• Footprint: Each new Java application takes up only the additional footprint for extra heap it requires and extra classes it loads; the footprint required for core classes shared with other Java applications is once again free.

Free? Did you say Free? Where can I get some? We need this! Why isn't it in the platform yet? It'll be in the next release for sure. Right?

Okay, let me don my loud plaid suit and play the part of a used car salesman: "Well, it's really almost completely free ... but not quite." Here are the gotchas about this approach that are important to keep in mind before getting too swayed by the "Free" argument above:

• Someone's gotta take the hit: Obviously, MVM cannot magically make the startup and footprint issues go away completely; that stuff still has to be loaded from disk and stored in memory. So somewhere there will be a startup hit loading the data and a RAM footprint to hold the heap and class data. In particular, this hit will be taken by the first application to load into MVM (or perhaps some parent process that simply loads up MVM to begin with). It is the following Java applications (from the second one on) that get the benefit of the sharing.
• All for One and One for All: If all of these Java applications are running within the same process, this means that any one of them can kill all of them. I believe that MVM protects around simple things like calls to System.exit() and other Bad Things happening at the Java level. But what if some native code does something awful and crashes? Or worse, what if some native code calls into some driver or other operating system dependency and _that_ crashes? Then that crash will also take down the whole lot of them.

So these are what my reservations for Desktop apps using MVM really boil down to: the benefit is only there for situations where multiple Java applications are running simultaneously, and there is significant risk that one application can take down the lot of them.

The risk of crashing all apps running within MVM is so important that I would feel queasy about sticking in this kind of capability by default in the platform. I cannot be sure that all applications that your users will run will be robust enough (from the application down through the platform level down through the drivers and into the hardware) that I'm will to bet all of your users' other applications upon that.

And given that the MVM benefits of startup and footprint are visible only for situations in which multiple Java applications are running, it seems like the only interesting environment in which to run MVM is one in which multiple Java applications are running.

Let's put these things together: we don't want to run MVM by default due to the kill-them-all risk, and we only want to run MVM in situations in which there are multiple Java applications at work. It sounds to me like we've just entered a new category of Java applications which does not yet exist: "application suites".

Application Suites

The ideal situation I envision for MVM is one in which applications run in suites, or in some other way where they could elect to have themselves added to a particular MVM process. For example, someone might ship a desktop utilities suite, and other developers could add in other applications that want to run in that process. Or someone could supply a suite of related applications (CAD, office, linked enterprise apps) that are happy to live (and maybe die) together. Or there could be a "Game" suite that you could elect to run your game in (crashing all games running is less serious than crashing all air traffic control applications, for example). Or there could be something I'm not yet seeing, because it doesn't yet exist.

So? Why isn't it there yet?

So now, finally, I get down to the question of "Why isn't it in the platform yet?", or more specifically, why isn't MVM going to be included in Mustang? Well, frankly, it's always a question of tradeoffs, just like any software project.

Would we include it if we could? Sure! Given the caveats above (that it's not enabled by default, that there are mechanisms for running related applications in separate MVM processes, etc.), then I don't see a good technical reason why we couldn't ship it. But, given the niche category that I've backed this technology into with the reasoning above, is it a critical feature that we should focus on in preference to some other Mustang feature? Given that we have a finite number of developers, that there are lots of interesting features and fixes we are working on (that people are also screaming for), and that not everything can make it onto the Mustang plate, I believe we made the correct call here that MVM, seen in the light of my logic above, was simply not as important as other features that we elected to work on instead. Would you rather we spent our efforts on technologies that benefit all, or even most, of Java developers? Or on a feature like MVM which might be completely awesome for the folks that need it, but which (given the constraints I laid out above) are probably few in number today?

What do you think?

What would you do? Am I missing something here? Is there a vibrant community of "application suite" developers that's just waiting to happen? Or are there a preponderance of applications that would be willing to work within these constraints today? Join in a discussion above, or go to Greg's blog and hop onto discussions there. We're looking for feedback on this; we'd like to take the MVM discussion of the "We need it!" stage and into the "We understand the constraints, here's how we would like to use MVM."

Phil's Font Fixes

The bits are in: we've just integrated LCD Text support in J2SE! You can download the latest Mustang build and check it out (we integrated this feature into build 39, which should be live now).

Phil Race was hard at work over the last several months implementing this stuff. Here's what he had to say about it:

One of the most frequently requested features has been for the JDK to support subpixel text which optimises for LCD displays using the subpixel striping to increase the text resolution. Because of the way its applied and configured by users its considered a form of text antialiasing.

On 31st May the RFE for this had reached number 6 on the BugParade RFE list with 378 votes.

The good news is this is now implemented and in mustang build 39.

The main reason for implementing this is to help the Swing native Look and Feel classes for Windows and Gnome/GTK in their emulation of the respective platform font rendering. mustang b39 now supports all the text antialiasing modes needed to support this.

At the same time as implementing this, the Windows Look and Feel and the GTK Look and Feel have also been updated to track the user's desktop preferences and update in real time as the end user changes these.

Additionally the default Java Look and Feel aka "Metal" now reads the user desktop text antialiasing preferences on start up and applies them to the JDK fonts. When used together with the Metal "Ocean" theme (which uses plain fonts instead of bold) introduced in JDK 5, the result is quite pleasing to the eye.

In a nutshell what this means is that whether you use Metal, Windows or GTK Look and Feel, you will get the same antialiasing behaviour for fonts in Java applications as in native applications. You don't have to do anything. It just works out of the box.

This is the first delivery of this work, and there's more that can be done, but it hits the big need of fixing these Swing L&Fs.

There's fairly little new API involved, although some more is expected later, for example in Swing to provide authors of custom L&Fs access to the same information as Metal.

For those interested in the details the new API in b39 is all in Java2D. There are 5 new values for java.awt.RenderingHints.KEY_TEXT_ANTIALIASING which are supported on all platforms:

• VALUE_TEXT_ANTIALIAS_LCD_HRGB
• VALUE_TEXT_ANTIALIAS_LCD_HBGR
• VALUE_TEXT_ANTIALIAS_LCD_VRGB
• VALUE_TEXT_ANTIALIAS_LCD_VBGR
• VALUE_TEXT_ANTIALIAS_GASP

The first four correspond to the 4 possible different LCD subpixel configurations. Native GTK apps support all 4 of these On Windows in native apps you need at least XP to get LCD text support, whereas JDK supports it on all OSes. Also Microsoft only supports HRGB on XP and added HBGR in XP SP1. So JDK's support here is more complete than Microsoft's.

The final oddly named hint value is used by JDK to precisely emulate what windows "standard" font smoothing does. That's what everyone with a CRT needs/uses. Its a little confusing to a lot of people as it doesn't mean all text is antialiased. It uses a table in the font (called the 'gasp' table, hence the name) provided by the font designer which stipulate the sizes at which smoothing should be done, and often that means text is not antialiased.

There are a very few other API tweaks but these are the most interesting ones.

If anyone wants to try this out, download mustang build 39 and look at the SwingSet2 demo. Also the Font2DTest demo has been updated to let you set any of the new hints and view the effects with any font or text of your choice.

(Note: All of the following pictures looked horrible in both browsers that I tried, related to automatic image scaling in those applications. The images looked fine on a different system, so they may look fine for you as well, but if they look odd, try disabling automatic image resizing or just saving the images and loading them with a local image viewing application instead.)

Or you could just look at these PNG screenshots of the JTable demo tab from the SwingSet2 demo. Without LCD text:

and with LCD text:

Here is a screenshot which shows side by side the same fonts being rendered by Windows WordPad accessory and a small JDK app which uses the same fonts and text. The fonts used here are ones typically seen in windows apps.

Similarly, here's a snapshot comparing some of the more common fonts seen in Gnome apps on Linux side by side with the JDK rendering of these fonts. The Gnome text was rendered on Fedora Core3 in the "gedit" application. Since gedit can only use one font at a time, the text was snapshotted and stitched together using gimp for ease of comparison.

Note : these images are prepared for viewing on a "HRGB" LCD display. That's by far the most common. If you are using a CRT don't expect to see much improvement. Also if your LCD display isn't connected by a DVI connector you'll not get the best experience either. A VGA connector just doesn't have the precise addressibility needed to get good results from this.

So that's all the important news about it: check it out, download it, play with it, tell us what you think.

Now, the less important but more interesting part, at least to this graphics geek: how does it work? There's information out there on the web so you can chase this down if you want more details, but the basics of LCD text involve details of how the eye perceives color, and how we can use that physical reality, along with the physical construction of LCD monitors, to display a higher-quality anti-aliasing effect. I originally hoped to cover this geeky topic here, but when I crossed the 400th line of text, I realized that it was more of an article than a blog entry. I'm working on that article now and hope to publish it sometime next week; stay tuned...

In the meantime, download the release and play with it; we think you'll like it.

This work is licensed under a Creative Commons License.