Ethan Nicholas's Blog

Community: JavaDesktop Archives

Java Secrets Revealed #1

I know, I know, it's been far too long since I've made an entry. My younger son is ten months old now, so I suppose I should probably stop using "new baby" as an excuse for my laziness...

Ahem.

Before I joined Sun, I thought I knew a lot about Java. I had been using it for a decade and had dug into its innards more times than I could count. Anytime I ran into inexplicable Swing weirdness or whatnot I wouldn't hesitate to dive into the JRE's source code and study it, or even recompile the classes with my own diagnostic code added. I wrote my own classloaders, I manipulated bytecode on the fly, I even wrote my own compiler for a JVM-targeted language. I had earned the right to call myself a guru.

Or so I thought.

Joining Sun nearly two years ago was a humbling experience. You see, it turns out that knowing a lot about Java works as a third-party developer is very different than, say, having to figure out how to rip the JRE apart and reassemble it on the fly without running programs noticing (Java Kernel, for the uninitiated). I have had to learn more about Java's inner workings than I ever really wanted to know, and maybe you'll find some of it interesting. Towards that end I'm going to pick a couple of random topics to blather about here, with the intent of hopefully making this a semi-regular feature.

Why can Java Web Start specify JRE versions, but the Java Plug-In can't?

If you have worked with both JNLP programs and applets, you are no doubt aware of the incongruities. JNLP programs can specify which JRE version they need to run with, their memory settings, command-line arguments, and so forth. Applets, on the other hand, are stuck with whichever JRE is registered with the web browser, and have no control over any JRE settings. (JRE Settings can be changed via the Java Control Panel, but cannot be specified by or for individual applets.)

The limitation arises because the JRE which handles applets runs inside the web browser. It lives within the browser process and address space, and as far as the OS is concerned is merely another chunk of the browser's code, just as with any other plug-in. And you can't simply load more than one JRE into the same OS process, because they would have conflicting symbol definitions, entry points, and so forth. It would be like trying to boot two different operating systems on the same computer, without the benefit of (very sophisticated) tools like VMWare.

To fix this, you've got to run the JRE in a separate process, but have the applets appear within the web browser window. This, of course, introduces all sorts of challenges and requires some clever engineering, but fortunately people smarter than me were assigned to the task. A group led by Ken Russell has done just that, resulting in what is officially (and wordily) named Next-Generation Java™ Plug-In Technology.

The new plug-in behaves much more like Web Start, in that you can use JNLP files to specify JRE versions, memory settings, and command line arguments. It's smart enough to consolidate multiple applets into the same JRE if their settings are compatible, or spawn additional JREs as needed to make everyone happy. It also has some extremely cool tricks up its metaphorical sleeve which we will be revealing at JavaOne.

What is Class Data Sharing?

Prior to joining Sun, I had read a paragraph about Class Data Sharing somewhere, but didn't know much about it. Since then I have found that pretty much nobody outside of Sun seems to know anything about it either. That's a shame, because it's actually quite neat.

One of the JRE's biggest jobs when booting up is classloading. Hundreds and hundreds of classes are needed just to get the JRE up and running, and not just the obvious ones like Class, Object, and String. You're also going to need URL and its entourage (for URLClassLoader), PrintStream and related I/O classes (for System.out and System.err), lots of different collection and utility classes, reflection support, charset support, and hundreds more.

There are two huge drawbacks to this: first, the JVM has to parse the Java class file for each of these classes, as well as resolve and link the symbols, and (for commonly-used methods) compile the methods using HotSpot. And, of course, all of this work happens every time the JRE starts up. Second, because each individual JRE is parsing and possibly compiling the code independently, they all end up with their own independent copies of the resulting memory structures.

To combat this problem, Java 5 introduced a new feature called Class Data Sharing. The idea is that the JRE does all of the basic classloading and parsing just once, and stores the resulting memory structures in a file (bin/<jvm>/classes.jsa, with jsa standing for Java Shared Archive). The next time the JRE boots, it simply maps this file into memory, and can skip all of the messy classloading. In addition to performance, another benefit is the fact that a big chunk of the mapped bytes can be shared by all running JREs, so they do not each need an independent copy of all of the code.

Of course, as with everything the devil is in the details. Some of the classes in the archive perform initialization which isn't guaranteed to alway be the same (the AWT classes, for example, will do different things depending upon your display configuration), and I'm told that there are enough such cases that the feature was a lot trickier to implement than it might sound. Plus you've got to detect the cases where the rt.jar file has been modified, or the boot class path has been overridden, or something else has changed which makes the inherent assumptions burned into the classes.jsa file incorrect, so that class data sharing can be disabled for that particular JRE invocation.

If you use diff or a similar tool to compare JRE directories from various machines running the same JRE version, you'll most likely find that the classes.jsa files, and only those files, are different. That's because classes.jsa is actually generated on your machine, instead of packaged with the installer. One of the last things the JRE installer does is run the magic incantation java -Xshare:dump, which causes the shared archive to be generated. That way we don't have to increase the size of the installer further, and I don't know for sure but I suspect that some aspects of the file may be machine-dependent which would necessitate this approach anyway.

Until next time...

Hopefully that little look inside wasn't too boring. Provided anyone is interested, I'll continue to share tidbits about the inner workings of Java in future installments. Unless of course I forget, or get sidetracked...

Java Kernel Unmasked

In my last entry, I briefly introduced the major features of the upcoming Consumer JRE. I'd like to now go into details on my pet project, code-named Java Kernel.

Overview

As previously mentioned, the idea is to create a 'minimal' JRE which has enough code to run System.out.println("Hello world!") and... well, that's about it. Every class or native library that isn't strictly necessary to boot up the JVM is excluded.

This minimal JRE has a few tricks up its sleeve, of course. It can detect when you try to access a class, such as javax.swing.JFrame, which isn't currently installed. It will then go download and install a "bundle" containing the required functionality. As far as your program can tell, nothing unusual happened -- it requested javax.swing.JFrame, it got javax.swing.JFrame. The only real difference is that (due to the required download) the classload took longer than usual.

User Interface

Naturally, we display a progress dialog for any downloads taking a meaningful amount of time. If you use a freshly-installed Kernel JRE to run a Java program, you'll see a dialog telling you that a few components are being downloaded, and then the program window will pop up and life will continue as normal.

You usually won't see any other progress dialogs -- most programs download everything they need before the main window shows up. Even with the ones that don't, Swing and AWT are by far the biggest bundles you will end up downloading, and both of them will be there before the main window appears. The other bundles are mostly quite small and won't involve an objectionable delay (and, of course, if the delay is short enough we don't pop up a dialog at all).

Other than this, the Kernel JRE looks and feels exactly like any other JRE.

Bundles

The Kernel JRE is currently divided into a hundred or so different bundles. These bundles generally follow package boundaries -- if you touch any class in (say) java.rmi, the entire java.rmi package will be downloaded. This means you'll end up downloading more classes than strictly necessary to run your program, but the alternative, downloading classes one-by-one, would be ridiculously slow due to all of the individual HTTP requests involved. We are trying to strike the proper balance between reducing the number of bytes downloaded and reducing the number of HTTP requests made.

Some bundles involve more than one package. javax.swing, for example, is entirely useless without javax.swing.event and several other packages. Since they are so tightly interconnected, they are packaged together into a single bundle. A few bundles don't cleanly follow package lines. In java.awt, for example, it makes sense to separate out the subset of AWT used by Swing programs. A Swing program isn't likely to touch AWT components like java.awt.Button, so we have a separate bundle (internally named java_awt_core) which includes only the AWT classes that a typical Swing program would use.

Still not small enough...

We've got other space-saving tricks, as well. Take a look at one of the core, absolutely essential files in Java 6: jvm.dll. This is (obviously) the JVM itself, needed to run all Java code. It's 2.3MB. And that doesn't include any classes, launchers, the installer, the Java Plug-In, Java Web Start, or any of the other essential JRE features. When you're trying to deliver an entire JRE in under 2MB, the fact that one of the required files is 2.3MB puts you at a pretty severe disadvantage.

Compression helps, obviously, but it takes more than a good compressor to squeeze things down this small. Java Kernel has its own version of jvm.dll, which omits a lot of optional features like JVMTI and additional garbage collectors. The current prototype's jvm.dll is a much more svelte 1.1MB. And when the Kernel JRE finishes downloading itself in the background, it will swap in the good old full client JVM, so you won't be without these optional features for long.

Background Downloading

The Kernel JRE will continue to download its missing bundles in the background, whether they were specifically requested or not. Over a broadband connection, this will only take a couple of minutes, so the window of time during which you might run into missing bundles is brief.

After the last bundle is downloaded, the Kernel JRE will reassemble itself into an exact replica of the "normal" JRE. All of the disparate bundles will be repackaged into a unified rt.jar file, the Kernel JVM mentioned above will be replaced with the traditional client JVM, and so forth. A "finished" Kernel JRE will be byte-for-byte identical to a "normal" offline JRE.

But what if I want to pre-download everything I need?

The single most frequently asked question is "Can I force the Kernel JRE to go ahead and download everything I need, so that there are no pauses or download progress dialogs while my program is running?"

I mentioned during my JavaOne session that we were well aware of the need for this, and working on a solution, but that we weren't ready to discuss it yet. I'm pleased to announce that the plans for this have been finalized (well, as final as anything gets in the software industry...) and I can reveal them now.

The JDK will include a tool which allows you to assemble a "custom bundle" containing all of the classes and files needed by your particular program. You determine the entire set of JRE classes needed by your program (for instance by running java -verbose or by using a static analyzer) and then use this list to create the bundle.

(Command names and options likely to change)

> java -verbose -jar MyProgram.jar > class_list.txt
> jkernel -create custom_bundle.zip -classes class_list.txt

You can then install this bundle into a freshly installed Kernel JRE:

> jkernel -install custom_bundle.zip

You can run the jkernel -install command as part of your program's installation or startup. With a custom bundle installed, you can rely upon the absolute minimum set of classes and files needed to support your program, and thus get the smallest possible download size.

This isn't yet optimal for applets or web start programs, as (unlike standalone programs) they don't have the ability to install the bundle before they start to execute, and thus before any bundles are automatically downloaded. Ideally I'd like the ability to simply specify "And my program needs this custom bundle, also" in the applet tag or JNLP file somewhere -- the only question is whether we'll be able to get this into the first release or not.

Results

Remember how the Java 6 jvm.dll is 2.3MB by itself?

The Kernel JRE's installer includes jvm.dll, the other native files and hundreds of classes needed to boot the JVM, the Java Plug-In, Java Web Start, java.exe, javaw.exe, javaws.exe, the installation code, and various support libraries needed to support the installer (such as unpack200).

And it's only 1.9MB.

If you build a custom bundle containing the classes required to run a typical Swing program, it comes out to about 1.5MB, for a total download of around 3.4MB for the JRE + custom bundle. Bigger programs might use as much as 4MB-5MB of the total JRE size, but it would be rare to exceed that.

Compared to the current JRE's size of somewhere between 10MB and 15MB, depending on how you measure it, hopefully you will agree that this is quite an improvement.

So, I'm sure you've got lots of questions for me. Shoot.

Announcing the Consumer JRE (again!)

When Steve Jobs announced the iPhone at MacWorld, Mac fans were understandably upset that no other announcements were made. There was nary a mention of Macs, Mac OS X, or iPods -- and disgruntled fans pointed to this as evidence that Apple was ignoring these products.

A few of the saner voices in the audience took the stance that since nothing could possibly have competed with the iPhone announcement, there was no point in Apple even trying to talk about anything else until the iPhone furor died down. After seeing what happened at JavaOne, I'm inclined to agree with this particular theory.

The "iPhone effect" has struck again -- only this time it's the "JavaFX effect". We announced a bunch of exciting things at JavaOne 2007, but the news of JavaFX has inspired so much coverage and discussion that it's hard for anything else to get any press time.

The other big announcement, the one you might not have seen much (or any) coverage of, was the Consumer JRE. The Consumer JRE is a release of Java 6 targeted at making the end-user experience better, meaning smaller downloads, faster installs, better graphics performance, smoother installation, faster startup, better reliability, and a bunch of other nice enhancements.

The best part is that I've seen several references to a "rumored" Consumer JRE release. Considering that we publicly announced the Consumer JRE in front of thousands of developers, I think we can safely move this particular 'rumor' into the "confirmed" column.

In case you missed my JavaOne session about the Consumer JRE, here's what you should know:

• The Consumer JRE will be a Java 6 update release delivered in the first half of 2008.
• It features performance and usability enhancements geared towards easier, better, faster end-user distribution.
• Will include the Java Technology Deployment Toolkit, a suite of technologies enabling much simpler JRE detection and installation.
• The JRE is being modularized, so that bits and pieces of it can be downloaded as needed. In the current prototype, the download needed to support a typical Swing program is between 3 and 4MB.
• Java Quick Start Service will pre-load portions of the JRE into the system disk cache, substantially decreasing the average start-up time.
• A new and improved installer will streamline, simplify, and speed up the installation process.
• Future updates will be delivered in-place -- you will no longer inadvertently end up with fifteen different versions of the JRE on your system.
• Some of these features may be delivered sooner than others.

I'll go into more details about these specific features in the near future. But for now, at least be aware that the Consumer JRE is anything but a rumor.

Also, take note of this poll. Despite the dearth of coverage, it sounds like at least some folks caught the announcement.

Integrate JAR files into your Windows desktop

Dieter Krachtus just sent me a link to a project he's working on, a shell extension which allows you to treat JAR files as executable programs under Windows. Now, double-clicking on a JAR file has long caused it to be launched under "java -jar", but with the generic "Java document" icon it doesn't exactly scream "executable program". I'm not sure how many people even know that you can double-click on a JAR to launch it, and between that and the generic icon that probably explains why I've never seen a Java program which took advantage of that ability.

With the ability to embed multiple resolutions / color depths of icons directly into your JAR files, as well as Ant integration and a GUI, this looks like a nifty little project. It's currently limited by the fact that it has to be installed on the end-user's system to function, but... what if this sort of capability were integrated directly into the JRE? Is that something you would find useful?

It's also worth mentioning that, as a Mac user, I'm used to being able to "install" most applications by simply dragging them to my Applications folder or other convenient location, and "uninstall" them by dragging them to the trash. JAR files potentially represent the same capability offered to users of other platforms -- just download the JAR file, and that is the program, with no need to install it before using it or uninstall it when you're done with it. Just double-click on it to run it, and if you decide you don't want it anymore you merely need to delete it. I think there's quite a bit of merit to this idea.

Update: Sorry, I should have explicitly stated that Dieter does not work for Sun and this is not a Sun project -- it's just something I thought was neat. I should also mention that most of the credit goes to Chris Deckers, the project lead.

Grown-up games

Five little-known facts about Ethan Nicholas

• I ran a BBS (Bulletin Board System) when I was in high school. This was back before the Web existed and before most people had even heard of the Internet. A lovely young lady dialed in using a 1200 baud modem attached to an aging Tandy, I struck up a conversation with her, and eventually we started dating. That lovely young lady is now my wife. (We met before it was cool to meet people online.)
• I'm a college dropout. During my senior year, GeoCities bought an application I wrote and moved me out to California, so I dropped out of school and never looked back. That's how I ended up at Yahoo!, also -- they bought GeoCities less than a year later.
• I collect gems and minerals. These are just a few of them (click thumbnails for larger images). All told, I have over three hundred specimens in several different cases. This case is my favorite, because the glass platforms rotate.
  
• I turned the attic of my house into a movie theater. I like to play video games up there. The screen in the shot below is 160" diagonal, which is over thirteen feet. I contracted out the actual construction work (framing the walls, hanging drywall, and so forth) but did all of the electronics, wiring, and such myself. It has two rows of four seats each.
  
• I have a tattoo of a dragon on my left forearm. Everybody asks me if it hurt. Yes, it hurt. It hurt exactly as much as you'd expect getting stabbed with a needle ten thousand times would hurt. My wife has a tattoo on her back, but she said that getting hers "kind of tickled". Evidently I'm a sissy.
  

My most-used utility methods

I've been writing Java code for more than a decade now, and there are a handful of methods I've ended up copying & pasting (or, sadly, reimplementing) in virtually every program I've ever written. I'm not sure why these methods in particular seem to keep cropping up again and again, but nevertheless I end up using them everywhere.

send(InputStream in, OutputStream out)

This method takes data coming from an InputStream and dumps it into an OutputStream. This is useful for a lot of different things -- you can take data sent to you by a web server and dump it into a FileOutputStream, you can take the output and error streams of a process and dump them to System.out and System.err, and on and on.

public static void send(InputStream in, OutputStream out) throws IOException {
    byte[] buffer = new byte[2048];
    int c;
    while ((c = in.read(buffer)) > 0)
        out.write(buffer, 0, c);
}

Over the years I've implemented several variations of this basic idea. I've had send() methods that would return the number of bytes they copied, or transfer only a certain number of bytes before stopping, but they've all looked pretty similar.

readFully(InputStream in)

An extension of the send() method, this takes all of the data retrieved from an InputStream and returns it as a byte array for easy processing. This is potentially dangerous, and should only be used when you know in advance that the data is small enough to comfortably fit in memory.

public static byte[] readFully(InputStream in) throws IOException {
    ByteArrayOutputStream buffer = new ByteArrayOutputStream();
    send(in, buffer);
    return buffer.toByteArray();
}

An obvious variant of this (assuming a similarly modified send() method) is to fail if the data is bigger than some threshold size limit.

Character-based variants

The send() and readFully() methods can be trivially modified to work with Reader, Writer, and String instead of streams and byte arrays.

String replacement

Once upon a time I had a simple method replaceString(String src, String a, String b), which takes a String and replaces all occurrences of sequence A with sequence B. After many RFEs (by myself and others) to include this capability in String itself, along with lots of explanations about how the regular expression features in Java 1.4 did not in fact eliminate the need for this, the replace(CharSequence a, CharSequence b) method was finally added to java.lang.String in Java 1.5.

Now that the capability is in the JRE itself, my ten-year-old replaceString() method has at last been retired for good, and I couldn't be happier about that. Sometimes it's the little things in life...

What about you?

I've written lots of utility methods, of course, but these are the small handful that I seem to always need no matter what I'm doing. Given my background in client/server code, it's perhaps not surprising that they have to do with data transfer. What about you? Any methods that you just can't live without, that you've been copying from program to program for years?

What you should know about Secure Static Versioning

Sun recently released a Java security advisory titled Java Plug-in and Java Web Start May Allow Applets and Applications to Run With Unpatched JRE. As with any security advisory, it's important that you take note and ensure that your software is up-to-date -- in this case, the problem is fixed in Java 1.5.0_06 or higher. But a blog entry by the Washington Post's Brian Krebs raises some concerns about this particular security advisory and suggests that merely patching your machine may not be enough.

The security advisory admittedly wasn't very clear on this point, but if you have Java 1.5.0_06 or higher installed (which I imagine most of you do by now), you are in no danger from this issue, even if you also have older versions of Java on your system. While that's obviously good news, the fix for this issue may have an impact on some Java developers. If you deploy Java applets or unsigned Web Start programs, keep reading.

Java has always allowed you to keep multiple versions installed on the same computer at the same time. Whether you love this particular feature or hate it, there's no denying that it can be useful at times. Certainly as a developer I appreciate being able to have Java 5 and Java 6 on the same machine at the same time, and I know enterprises prefer to be able to certify their internal software against exactly one version of Java without worrying about employees accidentally changing the Java version out from under them.

But as with all significant decisions, there is no single right answer. What's right for developers and enterprises isn't necessarily as great in the consumer market, where users would generally prefer not to leave old versions of the software lying around after an upgrade. Unfortunately we can't just suddenly start removing older versions -- because Java has always worked this way, many programs depend on this behavior. They may take the Java VM's location and "burn it in" to their launch scripts or registry entries, and removing the specific version on which a program depends would then cause it to break. Various ideas on breaking out of this vicious cycle have been tossed around, but for the time being, this is just the way things work.

Unfortunately, it also led to a security hole (again, fixed in Java 1.5.0_06).

Sun has always responded promptly to any security problems with Java, quickly releasing a patched version which fixes the problem. But since the previous unpatched and unsafe versions have been left on your hard drive, a malicious program could potentially get access to them. Theoretically, a Java applet could have requested a specific older version of Java and used a known (and long-since patched) security hole in it to compromise your system, even though you had dutifully downloaded the security update. Clearly, this was a situation that had to be addressed.

The solution is what is known internally as Secure Static Versioning. Basically it boils down to "untrusted code can't use unpatched older versions of Java". Previously, if you had several versions of Java installed on your system, a program could request one of the older versions in order to exploit it. Now, no matter which version of Java an untrusted program requests, it will receive the highest installed version. The practical upshot of this is that untrusted code will always be run in the most secure Java environment available.

Signed, trusted Web Start programs are allowed to request whatever version of Java they want -- they're trusted, so they have full access to your system anyway. Applets (even if signed) will always be run in the latest version. The discrepancy is due to technical differences between Web Start and the Plug-In; I'll go into the details in a future entry.

With the quick overview out of the way, let me sum up in an FAQ:

1. How much danger am I in?

If you have the latest JRE (1.5.0_06 or later) installed on your system, none at all. All current JREs include the Secure Static Versioning change, so applets and sandboxed Java Web Start programs are unable to access older versions of Java.

If you don't have Java 1.5.0_06 or higher, you would be wise to go ahead and install the latest version. I'm not aware of any exploits "in the wild", but it certainly doesn't hurt to be safe.

2. Do I need to remove old versions of Java?

No. Applets and sandboxed Java Web Start programs aren't allowed to access older versions of Java. They don't pose any threat in the first place, so removing them won't change anything. If you do decide to remove older versions of Java, you need to be sure that none of the applications on your computer are using them first.

3. Do I have to change anything about my Java programs?

No. If you have a Java applet or sandboxed Java Web Start program, it will always run in the latest available version of Java without any changes on your part. As long as you test your software against newer versions of Java, you shouldn't encounter any problems.

4. What does this mean for standalone Java programs?

Nothing. Just like native programs, Java programs which run outside of the Java sandbox already have full access to your system. Requiring them to run in the latest version of Java wouldn't do anything to increase security.

So, that's that. What might have sounded like a scary security issue (OMG YOU NEED TO UNINSTALL JAVA!!!!11!!!1) turns out to be quite mundane: install the latest patch release of Java and you're completely safe. This is of course great advice no matter what software we're discussing -- you are running with all of the latest patches for your operating system, web browser, Flash Player, and everything else on your system, aren't you?

Oh, and while we're on the subject of updates...

If you update using Java Update, rather than downloading via java.sun.com, you may find that you don't end up with the very latest update release. That's normal, and it's a result of the fact that Sun distinguishes the latest "consumer version" of Java from the latest "developer / enterprise version". If you go to java.sun.com, you get the latest developer / enterprise version, which is the very latest and greatest code available. If you go to www.java.com or use Java Update, you end up with the latest consumer version, which might be a couple of update releases behind the developer version (but is otherwise identical).

In order to avoid swamping end-users with too many updates, only two or three versions of Java a year are made available as consumer versions. Naturally, security fixes (such as the one under discussion here) always warrant a new consumer version, so you're safe no matter how you choose to update your copy of Java.

"Java Browser Edition": New name, first steps

"Java Browser Edition" History

Some time ago I proposed the idea of a Java Browser Edition. The basic idea was that the current Java Runtime Environment is simply too big, and most programs require only a small subset of the functionality. The "browser edition" that I suggested would enable you to install exactly the subset of Java that your particular program required, but would be able to download all of the other functionality on demand (and thus be fully compatible with J2SE). I wasn't quite prepared for the response that this entry generated. In addition to generating a lot of comments and further discussions, it ultimately played a role in my getting hired by the deployment team at Sun.

I was cautioned by several folks at Sun that the Browser Edition would simply never happen. It would never be approved as a feature in the first place, and even if it were approved, we would never be able to actually pull it off. I'm told that this basic idea has actually been attempted within Sun twice before, and in both cases the resulting size reduction wasn't enough to be worthwhile. The core VM, it seems, is simply too big, and trying to make it smaller is too hard. There has even been a detailed analysis of the idea which paints a rather bleak picture of the potential gains.

New Name: Java Kernel

The feature did in fact get submitted as a proposal for Java 7, under the name "Java Kernel" (the idea being that you download a small "kernel" of Java functionality, which is in turn capable of downloading the rest of it). And, amazingly enough, it was accepted. And, lucky me, I'm part of the team responsible for implementing it. After having been told that it's been tried a couple of times before and that it's basically impossible -- not a situation which inspires tremendous confidence.

Building a minimal JRE

The first thing I have to do is establish that this project is feasible. Remember that even though it has been approved, it could alway be un-approved (disapproved?) at any point in the future if things aren't looking good. So I figured I would start out by creating a simple, stripped-down JRE installer that contained only the functionality necessary to run System.out.println("Hello world!"), to get an estimate of the size reduction we could expect. Stripping out the unecessary classes is easy -- you just run Java with the -verbose option to get a list of all of the classes it loads while running the Hello World program. Those classes are all that we need to include in rt.jar.

The real problem is the rest of the functionality. My devel build of the Java 6 JRE contains 683 files totalling 119MB. Many of them are not necessary to run Hello World, but which ones? Determining which files were truly necessary and which weren't could be a tough job, so I made my computer determine it for me. I wrote a simple program which would iterate through all of the files in the JRE. It would remove a file and then attempt to run the Hello World program using this stripped-down JRE. If the test succeeded, the file was evidently unnecessary. If the test failed, the file was deemed necessary and restored.

After going through all of the files in this fashion, I was left with an extremely minimal JRE that could run Hello World and... well, that's about it. But it at least provided a starting point. Building a working installer from this JRE was itself a challenge, because several of the files that weren't necessary to run Hello World were still necessary to successful install the JRE, but I persevered and now have a fully functioning, minimal JRE.

Results

I built two JREs using this methodology: one with a program that prints "Hello World" to System.out, and one with a program that displays an empty java.awt.Frame. Here are the results:

Things to note

Before you get excited, remember that this is just an experiment and that the JREs I built aren't the least bit useful. They don't include the Java Plug-In, Web Start, or indeed much of anything, and any "real" program will need at least some of these components. These JREs also do not have the ability to download the missing components, and will simply fail if an attempt is made to access missing functionality. The installers we ultimately ship with Java 7 may well be bigger than this.

Next steps

Despite the cautions above, I find these results extremely exciting. Keep in mind that so far we haven't done anything the least bit sophisticated -- just omitted unnecessary files and classes -- and we've already gotten the JRE below 3MB for a non-visual program. Classes compress extremely well, so this installer would stay under 3MB mark even with a lot of additional classes included. And there are still a lot of things we can do to improve the size further, such as break up big DLLs to get better granularity.

It's hard to say how big the final Java 7 installers will end up being, but my personal goal is to make an installer that can handle basic Java applets in under 3MB. This is a difficult goal, and it may end up being too optimistic, but we're going to get as close as we can. So, what do you think? If the Java installer were 3MB instead of 15MB, would you find the idea of using Java applets (or Java Web Start programs) more appealing?

Welcome to the Deployment team: My first week at Sun

I mentioned in my last entry that I have left Yahoo! and am now officially a Sun employee. After an all-too-short break between jobs, my first day with Sun was this past Monday, and it's been quite an experience so far.

As with joining any big company, most of my first week was spent trying to get someone to actually set up my access badge and email account, figuring out how to access documentation on various subjects (there is documentation, right?), and dealing with various other miscellaneous getting-started headaches. Most of that is sorted out now and I expect that I should actually be able to, you know, work starting next week.

The most exciting part so far has been the fact that I've gotten to be involved in the Dolphin planning sessions we're having this week. I've requested some deployment features in the past, including a gigantic whopper of one, and while I can't give away too many details, I can say that there is definitely some hope.

I mentioned wanting an "updatejava.exe" program which would allow you to install specific versions of Java upon request, tremendously simplifying the process of writing installers for Java programs. There's actually a very good chance of such a tool making it into Dolphin, although it would probably have a slightly different name. And lest I erroneously receive credit for this idea, I should point out that this feature was already being investigated before I even suggested it.

The "Browser Edition" I suggested in this entry is a more complex problem. When I wrote that entry, I was in the enviable position of being able to request ridiculous improvements and not having to actually write any of the code. As you can imagine, my position is quickly shifting from "Sun should add support for feature <X> right now!" to "Ummm... well... you see, that's a really hard problem and it would be a lot of work...". Regardless, I think it's okay if I reveal that there is a feature more-or-less identical to what I suggested in the infamous "Browser Edition" blog entry currently under consideration for Dolphin. This should not in any way, shape, or form be construed as a promise that we will actually do it -- in other words, don't get your hopes up -- but it's being considered. At the very least, you should be aware that Java applets are the subject of intense scrutiny around here and we are trying to figure out how to improve them, within the limitations of the time and manpower we actually have available to throw at the problem.

There's a lot of other neat stuff on the table, most of which I probably shouldn't talk about yet. Hopefully the tidbits I've tossed out so far aren't revealing anything that will get me in trouble... In any case, expect some neat stuff from Dolphin's deployment enhancements. It's also not too late to suggest things: we are definitely interested in your feedback.

So long, and thanks for everything

When you work at a major Internet company like Yahoo!, deployment is a Big Deal. You have millions of customers running every version of every OS imaginable, some with marginally working computers, and they all need to be able to run your software. And they need to run it now -- make them wait too long, or download too much, and they'll give up and move on to your competitors.

While I'm definitely a huge Java fan, it's a hard technology to deploy to end-users. If a particular user doesn't have Java installed, or doesn't have the right version of Java installed, there are major challenges surrounding the detection, installation, and upgrading process. Even if users have the right version of Java installed, its behavior in web browsers isn't necessary all that reliable. I posted a couple of high-profile rants about Java deployment issues recently, to try to call some attention to these issues.

I wasn't really expecting much of a response. I figured some fellow complainers would show up, we'd talk amongst ourselves for a little while, and that would be the end of things. I wasn't expecting Sun to even notice my complaints, let alone actually do something about them. I was happy to be proven wrong.

I was asked to put together a resume, and invited to interview with the Java Deployment team. After two rounds of phone interviews and a grueling eight-hour interview process in Burlington, I accepted an offer to join Sun, and will finally have the opportunity to address some of the problems that have been bugging me for so long. This is a really exciting change for me -- to finally be working on Java, instead of just with it, and to be able to influence where things are headed... well, it's a Java geek's dream come true. Or at least it's this Java geek's dream come true.

We're still working out the details, but I should be starting at Sun in about a month. Yahoo! is a great company, and has been very good to me over the years, but this was an opportunity I just couldn't pass up.

To dispel any rumors...

Before any rumors get started, let me be the first to say that just because I blogged about some deployment ideas does not mean that any of those ideas will necessarily get implemented. Sun obviously found them interesting, or I daresay I wouldn't have been hired, but there's a big difference between finding an idea interesting and actually putting in the time and money necessary to implement it. In particular, don't expect a Java Browser Edition -- much as I would love to see it happen, I'm not naive enough to believe that it's at all likely.

I do have a lot of ideas for improvements to the Java Plug-In and Java Web Start; reasonably small, practical features that will nevertheless make a huge difference in how easy it is to deploy Java programs. Hopefully some of them will actually get implemented eventually, but at this point it's far to early to speculate on how things will work out. Rest assured that I will be doing my best to push for easier deployment solutions, and I'm all ears if you have any suggestions of your own.

What about JAXX?

What does this mean for JAXX, the declarative XML user-interface language I'm working on? In the short term, not much. The position I was hired for has nothing to do with JAXX, and I will still be doing all JAXX work in my spare time, rather than as a Sun-sponsored activity.

What about the long term? Your guess is as good as mine. All I know for sure is that I have a lot of ideas for the future of JAXX, and will continue to crank away on it. If the Swing team decides to add a user interface language to Java at some point (which I know they have considered), I expect I would at least be involved in the discussion. Other than that... who knows?

Looking ahead

The decision to leave Yahoo! was both difficult and painful, but I think I made the right choice. I'm very excited to be joining Sun, and I hope that I will be able to really make a difference. Wish me luck!

The Great Switch

I'm on vacation with my family right now. Vacation time is pretty hard for me to come by -- one of the dangers of being "essential" is that nobody wants to let you leave -- so this is a noteworthy event, made possible only by the fact that I agreed to bring my cell phone and work laptop, ensure the availability of Internet access at my destination, and remain reachable twenty-four hours a day. When we arrived, I got out my laptop and booted it up to check my email. It got as far as showing a blank Windows desktop and then... sat there.

Uh-oh.

I spent a while fiddling with it, but sadly when your machine won't even boot into Safe Mode and you have no other bootable disks with you, there really isn't much you can do. So here I was, stuck without a functioning computer, when having a functioning computer and Internet connection was part of my vacation deal. A whole week without being able to check email, or read my webcomics, or being able to post blog entries... a whole week without Internet access of any kind.

I don't think I can take that kind of punishment, so I did whatever any true geek would do: I used this situation as an excuse to buy a new computer. I (a long-time Windows user) had been lusting after the new MacBooks for quite a while, and my wife was well aware of this. She was also well aware that Fathers' Day was just around the corner, and, well, to make a long story short I love my wife very much and I'm typing this on my new 13" MacBook.

Obviously I'm not the first Java programmer to realize that a Mac is pretty great Java environment. When I was at JavaOne, I was shocked at the number of Mac laptops being toted around -- it seemed like every other system was a Mac. But after setting my system up, installing Eclipse, and getting to work on it, I really don't understand how I managed to put up with Windows for so many years. My Mac runs all of the software I need, Java programs run as smooth as silk, and (despite having theoretically less power) it feels faster than my most powerful Windows system. I could spend all day babbling about all of the things I love about it, but one thing is certain: I'm not going back.

Oh, and the Windows laptop? I decided to leave it on for an extended period of time, and checked on it periodically. After eight hours, there was still no change, so I went to bed. When I woke up in the morning, I saw that it had actually managed to finish booting. So after somewhere between eight and sixteen hours of sitting there, it finally got to the desktop. I realize that this is pathological -- when your computer takes more than eight hours to boot, something is clearly screwed up and I can't just say "Ha! Windows sucks!", but I sure feel like saying exactly that. I was eventually able to fix it by disabling some startup items... but hey, I got a new Mac out of the deal. Thanks for dying, work laptop!

JAXX: new version, long-term plans

(For an introduction to JAXX, start here.)

First things first: JAXX 1.0.1 is finally out. This version contains a lot of bugfixes and significant improvements to the quality and size of the generated Java code. Download it here.

Now that the major 1.0 bugs are fixed and a solid baseline has been established, I'm making plans for the future. Where is JAXX headed? What's next? I've posted a first pass at the JAXX roadmap and am seeking feedback. It's still early and subject to change, and there will be a lot more detail added as time goes on -- but I think it's a fairly decent stab at where things are headed.

I'm particularly excited about the addition of animation, based on Chet Haase's Timing Framework. The first animation features are going to be simple and straightforward, based on the current CSS pseudoclasses. Right now you can use a pseudoclass to, say, make a label turn blue when moused over:

<style>
  #hoverLink:mouseover {
    foreground: blue;
  }
</style>

<JLabel id='hoverLink' text='Mouse over to turn me blue'/>

This effect is applied instantly -- the second the mouse enters the label, it turns blue. The initial animation features will allow you to have effects like this be applied gradually over time:

<style>
  #hoverLink:mouseover[duration=500ms] {
    foreground: blue;
  }
</style>

<JLabel id='hoverLink' text='Mouse over to turn me blue'/>

Note the [duration=500ms] on the pseudoclass. There will be other properties for controlling acceleration, deceleration, and perhaps other features of the animation. This a simple change, to be sure, but I don't want to go overboard yet. More dramatic animation features will be added in good time.

What else is going on with JAXX? You'll have to take a look at the JAXX roadmap -- just be sure to let me know what you think!

Mnemonic Magic

Swing's mnemonic system is based around two properties: mnemonic (or displayedMnemonic) and displayedMnemonicIndex. They're powerful enough to do everything you need, but then again, so is machine code. There are a number of problems and limitations with the skeletal mnemonic support built in to Swing.

The Problems

• They're annoying to define - One common approach is to use a properties file to define actions. You generally end up with a property for the action's name, a property for its mnemonic, and an (optional) property for its mnemonic index -- three properties for the name of each action.
• It's easy to accidentally duplicate mnemonics - if you add new actions, or build a new menu from existing actions, it's incredibly easy to forget that (say) both "Lock" and "Layout" are using 'L' as their mnemonic character
• It's difficult to spot mistakes - the only visual cue to a mnemonic is an underline. Using Windows XP with default settings, the underline doesn't even show up unless you hold the Alt key. Mistakes are easily overlooked, and there is no error reporting.
• The same action may need different mnemonics in different contexts - If an action appears (say) in both a menubar menu and a right-click context menu, a mnemonic character which works in one menu may conflict in the second menu. I once ran into a menu item with a short name which, in a particular context menu, conflicted with other menu items on every single character in its name. With the action defined by static properties, though, you have to use the same mnemonic everywhere... so what do you do? Not have a mnemonic anywhere just because it conflicts in one rarely accessed location?
• It poses serious problems for internationalization - A quick survey of the bug database turned up a number of bugs relating to incorrect translations of mnemonics and mnemonic indices: 6411189, 4983399, 4664265, 4735183. There are two general problems: first, all of these properties are interrelated, and it's easy to miss one of them during translation -- leading to incorrect mnemonics or (worse yet) a mismatch between the actual mnemonic and the underlined character. Second, translation is quite complicated because the translator has to check that the mnemonic doesn't conflict with any other mnemonics in every menu in which the action appears. If the folks at Sun are making these kinds of mistakes, what hope is there for the rest of us?

Because of these annoyances, the unfortunate fact is that most Swing programs (at least among the ones I've seen) don't actually use mnemonics at all. That's sad, especially when you consider that other toolkits don't seem to share this aversion for mnemonics.

The Solution

The solution I propose is twofold. First, combine all three properties into a single value. Second, eliminate the need to specify mnemonics at all in most cases.

Combining all three properties is quite easy. You just need to embed the mnemonic and mnemonicIndex information into the label itself.

Before:

action.saveAs.name          = Save As...
action.saveAs.mnemonic      = A
action.saveAs.mnemonicIndex = 5

After:

action.saveAs.name = Save _A_s...

I chose to use a pair of underscores surrounding the mnemonic character to identify it, as opposed to most toolkits which use a single escape character. Windows, for example, would have specified the label as "Save &As...". The advantage of the underscore encoding is that there is essentially no chance of ever "accidentally" specifying a mnemonic character, whereas you might legitimately try to use an ampersand in a control, which in Windows would lead to an incorrect mnemonic.

Being able to specify the mnemonic character in this fashion carries a lot of benefits. Because it's a single value, specifying it in properties files is much easier, internationalization is much easier, and it's impossible to accidentally have a mismatch between the index and the mnemonic character. While this is much easier to deal with than three separate properties, it doesn't solve some of the other thorny problems, like trying to prevent duplicate mnemonics.

The rest of the solution is automatically assigning mnemonics. This is easier than it sounds, because we tend to follow certain heuristics when assigning mnemonics to actions and labels, and we can just turn those heuristics into a program. The algorithm I use is as follows:

1. Try the first character in the string. Check to see if it is available (among other menu items in the menu or components in the window, as appropriate).
2. If that isn't available, try capitalized letters in the order in which they appear.
3. If no capitalized letters are available, try lowercase consonants.
4. If no lowercase consonants are available, try lowercase vowels.
5. If no lowercase vowels are available, give up.

So my framework automatically assigns mnemonics to all actions (and specified components) based on these rules. 99% of the time it picks the same mnemonic you yourself would have. If it doesn't do what you want, you can manually specify it using a pair of underscores around the character in question. You can also force it not to choose a mnemonic at all by putting two underscores in a row at the end of the string. This makes translators' lives far easier, because they can generally just not worry about mnemonics and let the program "do the right thing". Furthermore, my framework has automatic error checking and will, if assertions are enabled, throw an AssertionError when a menu or dialog contains duplicate mnemonic characters.

Unfortunately...

There are some other details, of course, like the API calls necessary to actually work with this framework, but they aren't relevant because I can't release the code to the public. It's part of a proprietary application which my employer owns the rights to, so you'll just have to use your imagination. Fortunately the code itself is relatively straightforward -- you could easily duplicate this setup if you wanted to, and probably save yourself a lot of time overall (if you're working on a big application). There is hope, however...

JSR 296

JSR 296, "Swing Application Framework", aims to (among other things) define a standard way of representing and managing Actions. My hope is that, as part of this, JSR 296 will include a better means of managing mnemonics than having to specify three properties individually. At the very least I'd like to see the mnemonic be able to be embedded directly into the string (as in "Save _A_s...", "Save &As...", or something equivalent), but trust me when I say that the automatic mnemonic management is incredibly nice also.

Considering that I have a seat on the JSR 296 expert group, I will definitely be pushing for some sort of solution to these issues. I haven't actually discussed this with anyone yet, though, so maybe they already have an even better solution in mind (yay!) or have decided that this issue isn't worth pursuing (boo!). It's also entirely possible that I'm the only weirdo that considers this a significant issue in the first place.

JAXX

If you've used my JAXX framework, you may be a little surprised about this entry, considering that JAXX doesn't do automatic mnemonic management or allow you to embed mnemonic markers directly into the label. That was a deliberate, albeit painful, decision, and it comes back to JSR 296. Given that there's eventually going to be a standardized Swing application framework, I'm taking a wait-and-see attitute, carefully avoiding doing anything in JAXX which might conflict with the Swing framework-to-be. If JSR 296 does define a standard way to identify mnemonics, I'll use the same syntax. And if it doesn't, I'll do it my way. Regardless of the outcome, I expect that JAXX will eventually support this sort of mnemonic magic.

What do you think?

So, what do you think? Do you agree that Swing's approach to mnemonics could use some improvements? Want automatically managed mnemonics? Hate the idea? Like being able to specify mnemonics directly in the string, but don't like the syntax? Or am I just altogether crazy?

More deployment woes

Scott Delap (of ClientJava.com fame) just sent me a gem of an article: a Washington Post blogger complaining about how hard it is to update Java. I have blogged previously about deployment issues, and it remains my single biggest complaint about the Java platform. So here it is from another perspective, a highly detailed and thoroughly sordid look at Java on the client side. The results aren't pretty. If a technically savvy user is having this much trouble just updating Java to the latest version, how are average-Joe users supposed to manage?

He touches on the Java version numbering confusion, which is something near and dear to my heart. Is the latest version of Java 1.5 or Java 5.0? Depends where and how you ask. I've been complaining (some might call it "bitching") about the schizophrenic version numbering since the Java 1.2 / "Java 2 Standard Edition" days. I have brought my complaints up with a number of Sun engineers, and every time I was at least hoping for something along the lines of a defeated sigh followed by "I know, it's stupid. It's marketing's fault." That at least would have made me feel better. Instead I have received a number of patient lectures about how, deep down, it actually does make sense and needs to be this way. Well, I don't agree. It's silly and needs to be fixed. When a question as simple as "What version of Java am I running?" needs an answer that begins with "Well, it depends..." something is deeply wrong. It is not okay for Java to refer to itself 5.0 in some places and 1.5.0_06-b05 in others. Pick one. I don't care which. But pick one and stick with it.

For the rest of the issues, you'll have to go read the original post. It's a good read, although it did sort of make me want to take a shower afterward.

In addition to Brian Krebs' excellent complaints, I have one more to add from the developer side of things. Why is there no easy way to say "I need Java 1.4.2 or higher" and actually get Java installed and updated properly? I want the basic Web Start functionality of updating the Java version based on version selector strings, like "1.4.2+". Except I want it to A) not require me to be using Web Start, B) not require Java to be currently installed at all, and C) function reliably. I basically just want a little utility, perhaps "updatejava", which will check to make sure the right version of Java is installed, download and install it otherwise (or run the installer from a path I specify), set JAVA_HOME to point to it, and return a code indicating whether or not it was successful. Such a utility would simplify all of my Java installers so much it isn't even funny, and I'm sure I'm not alone. Wouldn't it be fantastic to just be able to run "updatejava 1.4.2+", check for a successful return code, and then be able to trust that there was a working 1.4.2 or higher installation of Java pointed to by a correct JAVA_HOME? Does such a utility already exist? If not, how have eleven years gone by with nobody writing one?

(Yes, I know, I should shut up and write one myself... but hey, I'm already occupied. Besides, given the profusion of platforms, Java versions, and issues to work around, this feels to me like the sort of thing that would need Sun support, or at the very least significant resources behind it, in order to succeed.)

Won Point Oh

(If you have no idea what JAXX is, take a look at Introducing JAXX)

I'm usually pretty good about hitting deadlines, but this one was really close. My JavaOne session (TS-4265 User Interfaces in XML: The JAXX Framework) is on Thursday, and I had planned since the very beginning to have JAXX 1.0 out by then, preferably a few weeks prior. Since it is now the day before my presentation and I am just now making an entry about the 1.0 release... well, you can do the math.

Admittedly, there was a bit of scope creep. As I described in my last blog post, I ended up fixing JAXX to support circular dependencies, which is something I had planned to hold off until post-1.0. During the beta, JAXX transitioned from a brain-dead code generator into a relatively sophisticated two-pass compiler, and both JAXX and I are certainly better off for the experience.

Now, JAXX isn't perfect. It is a 1.0 release, after all. But the few known bugs are all pretty minor, and I feel confident in saying that it's ready for prime time. So if the idea of being able to create a user interface by writing simple XML files, complete with sophisticated CSS stylesheet support and a whole lot more, sounds interesting to you -- you might want to take a look at JAXX (http://www.jaxxframework.org/).

JAXX user interface language: marching towards 1.0

If you're not familiar with JAXX, it is an open-source XML language for creating Swing GUIs that I'm working on. For a more detailed introduction, Introducing JAXX: A New Way to Swing and Style Swing components using CSS are good places to start.

Today's news is the release of JAXX 0.96, and in particular the fix to circular dependency compilation. Previous versions of JAXX couldn't deal with circular dependencies -- A.jaxx depends on B.java and B.java depends on A.jaxx (perhaps indirectly) -- and fixing this problem was an enormous chunk of work.

The biggest challenge with circular dependencies is that you can't generate Class objects until the classes are fully compiled, and JAXX couldn't fully compile classes until their dependencies were fully compiled (as it depended on the presence of Classes). If you have circular references, you also can't compile the dependencies first, because the dependencies themselves depend on the class you're currently trying to compile. That is, of course, what makes it "circular".

Without being able to depend upon the availability of Class objects, you also can't use Class-dependent APIs like java.beans.Introspector or reflection. Because JAXX was (quite naturally) using Introspector to identify objects' properties and events, the fact that I had to go cold turkey and stop using Class objects altogether was tough to swallow.

To solve this problem, JAXX 0.96 contains a (mostly complete) mirror of the reflection APIs and Introspector. These clones can operate on Class, just like their built-in cousins, but can also operate on uncompiled Java source files and uncompiled JAXX source files. With this newfound flexibility, JAXX can compile against dependencies which have themselves not yet been compiled -- and therefore handle circular reference chains with aplomb.

JAXX is, as far as I'm concerned, ready for prime time. 0.96 is scheduled to be the final beta, and barring unforeseen problems, the golden 1.0 version will be almost identical. So please do me a favor and take a look -- this is your last chance to request changes or report bugs before 1.0 is released.

JAXX 0.96 can be downloaded from http://www.jaxxframework.org/

Understanding Weak References

Some time ago I was interviewing candidates for a Senior Java Engineer position. Among the many questions I asked was "What can you tell me about weak references?" I wasn't expecting a detailed technical treatise on the subject. I would probably have been satisfied with "Umm... don't they have something to do with garbage collection?" I was instead surprised to find that out of twenty-odd engineers, all of whom had at least five years of Java experience and good qualifications, only two of them even knew that weak references existed, and only one of those two had actual useful knowledge about them. I even explained a bit about them, to see if I got an "Oh yeah" from anybody -- nope. I'm not sure why this knowledge is (evidently) uncommon, as weak references are a massively useful feature which have been around since Java 1.2 was released, over seven years ago.

Now, I'm not suggesting you need to be a weak reference expert to qualify as a decent Java engineer. But I humbly submit that you should at least know what they are -- otherwise how will you know when you should be using them? Since they seem to be a little-known feature, here is a brief overview of what weak references are, how to use them, and when to use them.

Strong references

First I need to start with a refresher on strong references. A strong reference is an ordinary Java reference, the kind you use every day. For example, the code:

StringBuffer buffer = new StringBuffer();

creates a new StringBuffer() and stores a strong reference to it in the variable buffer. Yes, yes, this is kiddie stuff, but bear with me. The important part about strong references -- the part that makes them "strong" -- is how they interact with the garbage collector. Specifically, if an object is reachable via a chain of strong references (strongly reachable), it is not eligible for garbage collection. As you don't want the garbage collector destroying objects you're working on, this is normally exactly what you want.

When strong references are too strong

It's not uncommon for an application to use classes that it can't reasonably extend. The class might simply be marked final, or it could be something more complicated, such as an interface returned by a factory method backed by an unknown (and possibly even unknowable) number of concrete implementations. Suppose you have to use a class Widget and, for whatever reason, it isn't possible or practical to extend Widget to add new functionality.

What happens when you need to keep track of extra information about the object? In this case, suppose we find ourselves needing to keep track of each Widget's serial number, but the Widget class doesn't actually have a serial number property -- and because Widget isn't extensible, we can't add one. No problem at all, that's what HashMaps are for:

serialNumberMap.put(widget, widgetSerialNumber);

This might look okay on the surface, but the strong reference to widget will almost certainly cause problems. We have to know (with 100% certainty) when a particular Widget's serial number is no longer needed, so we can remove its entry from the map. Otherwise we're going to have a memory leak (if we don't remove Widgets when we should) or we're going to inexplicably find ourselves missing serial numbers (if we remove Widgets that we're still using). If these problems sound familiar, they should: they are exactly the problems that users of non-garbage-collected languages face when trying to manage memory, and we're not supposed to have to worry about this in a more civilized language like Java.

Another common problem with strong references is caching, particular with very large structures like images. Suppose you have an application which has to work with user-supplied images, like the web site design tool I work on. Naturally you want to cache these images, because loading them from disk is very expensive and you want to avoid the possibility of having two copies of the (potentially gigantic) image in memory at once.

Because an image cache is supposed to prevent us from reloading images when we don't absolutely need to, you will quickly realize that the cache should always contain a reference to any image which is already in memory. With ordinary strong references, though, that reference itself will force the image to remain in memory, which requires you (just as above) to somehow determine when the image is no longer needed in memory and remove it from the cache, so that it becomes eligible for garbage collection. Once again you are forced to duplicate the behavior of the garbage collector and manually determine whether or not an object should be in memory.

Weak references

A weak reference, simply put, is a reference that isn't strong enough to force an object to remain in memory. Weak references allow you to leverage the garbage collector's ability to determine reachability for you, so you don't have to do it yourself. You create a weak reference like this:

WeakReference<Widget> weakWidget = new WeakReference<Widget>(widget);

and then elsewhere in the code you can use weakWidget.get() to get the actual Widget object. Of course the weak reference isn't strong enough to prevent garbage collection, so you may find (if there are no strong references to the widget) that weakWidget.get() suddenly starts returning null.

To solve the "widget serial number" problem above, the easiest thing to do is use the built-in WeakHashMap class. WeakHashMap works exactly like HashMap, except that the keys (not the values!) are referred to using weak references. If a WeakHashMap key becomes garbage, its entry is removed automatically. This avoids the pitfalls I described and requires no changes other than the switch from HashMap to a WeakHashMap. If you're following the standard convention of referring to your maps via the Map interface, no other code needs to even be aware of the change.

Reference queues

Once a WeakReference starts returning null, the object it pointed to has become garbage and the WeakReference object is pretty much useless. This generally means that some sort of cleanup is required; WeakHashMap, for example, has to remove such defunct entries to avoid holding onto an ever-increasing number of dead WeakReferences.

The ReferenceQueue class makes it easy to keep track of dead references. If you pass a ReferenceQueue into a weak reference's constructor, the reference object will be automatically inserted into the reference queue when the object to which it pointed becomes garbage. You can then, at some regular interval, process the ReferenceQueue and perform whatever cleanup is needed for dead references.

Different degrees of weakness

Up to this point I've just been referring to "weak references", but there are actually four different degrees of reference strength: strong, soft, weak, and phantom, in order from strongest to weakest. We've already discussed strong and weak references, so let's take a look at the other two.

Soft references

A soft reference is exactly like a weak reference, except that it is less eager to throw away the object to which it refers. An object which is only weakly reachable (the strongest references to it are WeakReferences) will be discarded at the next garbage collection cycle, but an object which is softly reachable will generally stick around for a while.

SoftReferences aren't required to behave any differently than WeakReferences, but in practice softly reachable objects are generally retained as long as memory is in plentiful supply. This makes them an excellent foundation for a cache, such as the image cache described above, since you can let the garbage collector worry about both how reachable the objects are (a strongly reachable object will never be removed from the cache) and how badly it needs the memory they are consuming.

Phantom references

A phantom reference is quite different than either SoftReference or WeakReference. Its grip on its object is so tenuous that you can't even retrieve the object -- its get() method always returns null. The only use for such a reference is keeping track of when it gets enqueued into a ReferenceQueue, as at that point you know the object to which it pointed is dead. How is that different from WeakReference, though?

The difference is in exactly when the enqueuing happens. WeakReferences are enqueued as soon as the object to which they point becomes weakly reachable. This is before finalization or garbage collection has actually happened; in theory the object could even be "resurrected" by an unorthodox finalize() method, but the WeakReference would remain dead. PhantomReferences are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to "resurrect" an almost-dead object.

What good are PhantomReferences? I'm only aware of two serious cases for them: first, they allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that. This isn't generally that useful, but might come in handy in certain very specific circumstances like manipulating large images: if you know for sure that an image should be garbage collected, you can wait until it actually is before attempting to load the next image, and therefore make the dreaded OutOfMemoryError less likely.

Second, PhantomReferences avoid a fundamental problem with finalization: finalize() methods can "resurrect" objects by creating new strong references to them. So what, you say? Well, the problem is that an object which overrides finalize() must now be determined to be garbage in at least two separate garbage collection cycles in order to be collected. When the first cycle determines that it is garbage, it becomes eligible for finalization. Because of the (slim, but unfortunately real) possibility that the object was "resurrected" during finalization, the garbage collector has to run again before the object can actually be removed. And because finalization might not have happened in a timely fashion, an arbitrary number of garbage collection cycles might have happened while the object was waiting for finalization. This can mean serious delays in actually cleaning up garbage objects, and is why you can get OutOfMemoryErrors even when most of the heap is garbage.

With PhantomReference, this situation is impossible -- when a PhantomReference is enqueued, there is absolutely no way to get a pointer to the now-dead object (which is good, because it isn't in memory any longer). Because PhantomReference cannot be used to resurrect an object, the object can be instantly cleaned up during the first garbage collection cycle in which it is found to be phantomly reachable. You can then dispose whatever resources you need to at your convenience.

Arguably, the finalize() method should never have been provided in the first place. PhantomReferences are definitely safer and more efficient to use, and eliminating finalize() would have made parts of the VM considerably simpler. But, they're also more work to implement, so I confess to still using finalize() most of the time. The good news is that at least you have a choice.

Conclusion

I'm sure some of you are grumbling by now, as I'm talking about an API which is nearly a decade old and haven't said anything which hasn't been said before. While that's certainly true, in my experience many Java programmers really don't know very much (if anything) about weak references, and I felt that a refresher course was needed. Hopefully you at least learned a little something from this review.

Reinventing GridBagLayout

Java suffers from a layout crisis. It ships with a bunch of poorly-thought-out layout managers, a few (like GridLayout and BorderLayout) that are decent within their limited niche, and... GridBagLayout. Despite a few warts, GridBagLayout is powerful enough to handle almost any layout task -- but it's so ridiculously difficult to use that most programmers avoid it like the plague.

There have been many attempts to replace GridBagLayout, with varying degrees of success (TableLayout, SpringLayout, GroupLayout, and FormLayout, just to name a few) but from what I have seen, most people just drop back to using simpler layouts, like BoxLayout, in nested panels. This is a bad idea. For one thing, it complicates component setup and makes rearranging the UI and controlling resizing behaviors much more difficult. For another, it results in many additional components. A setup that could be done with a single GridBagLayout might take four or more panels with simpler layouts -- and every extra level of nesting is another level that has to be processed during repaints, event handling, and layout, not to mention the unnecessary memory consumption. Memory and performance are already at a premium in Java, so you can ill-afford to create more components than necessary to get the job done.

GridBagLayout isn't fundamentally a bad layout manager -- it's just too hard to use. If it were simpler, I don't think most of the "GridBagLayout replacements" would have a reason to exist, as there is very little that GridBagLayout can't do. While building the JAXX user-interface language, I needed a powerful, easy-to-use layout system, and (perhaps surprisingly) I settled on GridBagLayout.

JAXX offers a Table component which is built on top of GridBagLayout. I briefly mentioned Table in my introduction to JAXX, but didn't go into any details. The goal of the <Table> tag was to offer all of GridBagLayout's power, while removing the tedium and error-prone-ness (error-prone-itude?) that characterizes more typical GridBagLayout usage. Take a look at a simple table:

<Table>
  <row>
    <cell><JLabel text='Username:'/></cell>
    <cell><JTextField id='username'/></cell>
  </row>
  
  <row>
    <cell><JLabel text='Password:'/></cell>
    <cell><JPasswordField id='password'/></cell>
  </row>

  <row>
    <cell columns='2'>
      <JPanel layout='{new GridLayout(1, 2, 6, 6)}'>
        <JButton text='OK'/>
        <JButton text='Cancel'/>
      </JPanel>
    </cell>
  </row>
</Table>

Here's what it looks like when run:

GridBagLayout isn't perfect, of course -- I needed to use a sub-panel to get the buttons right -- but that was sure better than coding GridBagLayout by hand, wasn't it?

JAXX's Table tag offers a lot more features, like the ability to specify GridBagConstraints attributes on each <cell>:

<cell weightx='1' fill='horizontal'><JTextField id='username'/></cell>

You can also specify constraints on a <row>, in which case they apply to each cell in the row (unless overridden). You can even specify default constraints for every cell by putting them on the <Table> tag itself:

<Table insets='3, 3, 3, 3' anchor='northwest'>

Table-level defaults can be overridden on either a per-row or per-cell basis.

I think that JAXX's <Table> tag breathes new life into the much-maligned GridBagLayout, allowing it to flex its power while removing (most of) the cursing that using GridBagLayout typically entails. Eventually JAXX will offer specialized support for other advanced layout managers, like FormLayout, but for the time being GridBagLayout is surprisingly powerful when it isn't hampered by the manual constraints wrangling of days past.

For more information on JAXX, take a look at www.jaxxframework.org.

Creating a Service Provider Interface

While working on my XML user interface language, JAXX, I wanted to provide a mechanism for users to add support for additional tags and data types. As JAXX is a command-line compiler, a run-time API to add additional features would be very awkward to access, so a Service Provider Interface (SPI) seemed like a natural fit.

In case you aren't familiar with SPIs, they have a tantalizing proposition: just put a special JAR file somewhere on your class path, and the features in the JAR file will be found and made available. Many of Java's internal APIs, such as JNDI and javax.imageio, have SPIs, which makes it a snap to plug in new features.

So, great, I needed to write an SPI. I spent some time wrestling with search engines to find documentation on how to actually create an SPI, and found nothing. Tons of information about how to interact with the SPIs built into Java, but absolutely nothing about how to create one. There was nothing left to do but dig through Java's source code to figure out what Sun was doing, so I could shamelessly copy it.

The answer turned out to be embarrassingly simple. The method ClassLoader.getResources() returns an Enumeration of all resources with a given name, like myspi.properties. To implement an SPI, you have each SPI JAR contain (say) a properties file with the same name in the same location. When you use ClassLoader.getResources() to get a list of all such properties files, you will find one properties file for each JAR on the class path which implements your SPI.

The properties file should contain whatever information is necessary for you to make use of the features in the JAR file. This typically takes the form of properties set to the names of classes found in the JAR file, which can then be loaded and used.

In the case of JAXX, the properties file is named jaxx.properties and is located at the root of the JAR file. It contains a single property jaxx.initializer, which should be set to the name of a class in the JAR file. This class must implement the interface jaxx.spi.Initializer. JAXX can then, via the magic of ClassLoader.getResources(), easily find all such initializer classes and load the support they contain.

Presto! A fully-functioning SPI, just like the ones Sun uses.

Java 2 Browser Edition

The problem

In my day job at Yahoo!, I face a frustrating problem: Java is the most powerful browser-based technology available, easily besting competitors like Ajax and Flex, and yet I can't use it. These are the main reasons:

It's too big - Sun is (rightfully) proud of the fact that 90% of computers already have Java installed, but that still means that 10% of my users are stuck having to download a 7MB plugin. They might be willing to do it for a compelling enough application, but they definitely won't do it for something that could just as easily have been done in Ajax or Flex.

It's too slow - Sun has been working hard on Java's performance, and it shows. Once it gets up and running, it runs rings around every other rich client technology. Flash, for instance, is pitifully slow compared to Java. But the problem is that bit about "once it gets up and running". It can take thirty seconds or more to cold-start the JVM on an average desktop machine, compared to "instant" for both Ajax and Flash. A user might -- might -- tolerate that once or twice. They certainly won't tolerate it over and over again, which makes Java applets a good way to lose repeat visitors.

It's too hard to install and upgrade - Compare Java's installation process to Flash's installation process. I think that's all I need to say here.

It's too unreliable - I have seen a number of computers that simply won't run Java in the browser. You can uninstall Java, reinstall it, uninstall and reinstall the browser(s), and it still won't run applets. It just sits there, making no visible attempt to start the applet. If I, as a Java developer, can't figure out why such-and-such computer won't run Java applets, do I want to rely on my users being able to figure it out? I have never seen a system that inexplicably wouldn't play Flash movies or run JavaScript.

The solution

If Java were able to offer an experience comparable to the Flash plug-in, Yahoo! would be using it all over the place. I'm sure the same goes for a lot of companies. If Macromedia Flex, which is a miserably buggy and downright awful product (at least as of version 1.5), can gain the kind of attention it has, I don't believe it's too late for Java to make a resurgence in the browser. It won't be easy, though. Here's what I want to see:

A 1MB download

There is of course no way the entire JRE can be crammed into 1MB, no matter how good the compression is. And yet I think it can be achieved. The most important part will be segmenting up the JRE into chunks which can be (automatically) downloaded and installed separately. I very much doubt that most Rich Internet Applications need JNDI support, for instance, or the ability to do XSLT transformations. By carefully choosing the core set of features to bundle, the JRE size could be drastically reduced. Likewise, I'd be happy with a simpler virtual machine -- as long as it's substantially faster than Flash (which even a Java 1.1-era JIT could easily manage), it's good enouch for RIAs.

The goal would be to have your application specify the set of features it needs: Swing and XML parsing support, for instance. If the plug-in already had those features installed, great. If not, it would automatically and seamlessly go download them. If the plug-in wasn't installed at all, you would be directed to an installer which contained those (and only those) features. Ideally the installable features would be fairly fine-grained, keeping in mind that a small download is absolutely essential for success.

Ideally, J2SE would be exactly the same as J2BE with all of the optional features installed. But if it really became necessary, I would be okay with having J2BE being a subset of J2SE, along the lines of J2ME. I don't need (or even necessarily want) all of Java's features in a browser plug-in. As long as there is complete upwards compatibility (all J2BE classes work unmodified under J2SE) and partial downwards compatibility (J2SE classes work as long as they don't use any unsupported APIs), I think it's an acceptable trade.

Instant startup

For a long-running server application, Java's start-up time is essentially irrelevant. For a traditional desktop application, it's annoying but not the end of the world. For a typical short-lived browser-based application, though, it's murder. In every usability study I have ever attended, one fact comes through loud and clear: users are impatient. They don't like to read, they don't like to think, and most of all they don't like to wait. It sucks, but it's a fact of life and we as software developers need to live with it. To be competitive, Java applications must be able to start up almost instantly. I'm willing to accept them being a bit slower to start than Flash applications, but only a bit.

A better installer

It must be as fast and as easy as Flash to install. Likewise upgrades should be seamless -- if an applet requires a higher version of the plug-in, the user is notified, the new version is downloaded and installed with no further messaging, and the applet starts. End of story.

Improved reliability

Every customer that can't use my tools is a customer I'm going to lose. So if I'm going to commit to a browser-based technology, it had better be reliable. Damned reliable.

Is there still hope?

Maybe. There is no question that the idea of Java in the browser is currently dead, but I don't think it's too late for a comeback. Java is so much better than competing technologies that it's almost absurd. If Sun were to deliver on these features, I would switch to using Java in the browser in a heartbeat. I suspect that goes for a lot of you, as well. I don't think the question is so much can Sun win the war, but are they willing to? That, my friends, is a question I can't answer.

Style Swing components using CSS

Swing does a great job of separating data (the models) and controls (the components themselves), but it really doesn't do a good job of separating controls from presentation (the visual appearance of the controls).

Pluggable looks-and-feels help to a degree, but they are complicated to write and maintain, and on top of that they affect the appearance of every component of a particular type. There are lots of good reasons for having components of the same type have different styles attached to them, and the present-day solutions to doing this in Swing aren't fantastic.

CSS is a natural fit here. It was designed to solve exactly this problem, and on top of that it's a familiar technology which many Java programmers are already comfortable with. When writing the open-source JAXX framework, I chose to use CSS as its style language, and I think it brings unprecedented power and control to Java. Let's take a look at a simple example, the (slightly modified) Calculator from jaxxframework.org:

<Application title='Calculator'>
  <script source='Calculator.script'/>
  
  <Table fill='both' id='table'>
    <row>
      <cell columns='4'><JLabel id='display' text='0'/></cell>
    </row>
    
    <row>
      <cell columns='2'><JButton id='c' label='C' onActionPerformed='clear()' styleClass='clear'/></cell>      
      <cell><JButton id='ce'     label='CE' onActionPerformed='clearEntry()' styleClass='clear'/></cell>
      <cell><JButton id='equals' label='=' onActionPerformed='equal()' styleClass='operator'/></cell>
    </row>
    
    <row>
      <cell><JButton id='d7'   label='7' onActionPerformed='digit(7)' styleClass='digit'/></cell>
      <cell><JButton id='d8'   label='8' onActionPerformed='digit(8)' styleClass='digit'/></cell>
      <cell><JButton id='d9'   label='9' onActionPerformed='digit(9)' styleClass='digit'/></cell>
      <cell><JButton id='plus' label='+' onActionPerformed='add()' styleClass='operator'/></cell>
    </row>

    <row> 
      <cell><JButton id='d4'       label='4' onActionPerformed='digit(4)'   styleClass='digit'/></cell>
      <cell><JButton id='d5'       label='5' onActionPerformed='digit(5)'   styleClass='digit'/></cell>
      <cell><JButton id='d6'       label='6' onActionPerformed='digit(6)'   styleClass='digit'/></cell>
      <cell><JButton id='subtract' label='-' onActionPerformed='subtract()' styleClass='operator'/></cell>
    </row>

    <row>
      <cell><JButton id='d1'       label='1' onActionPerformed='digit(1)' styleClass='digit'/></cell>
      <cell><JButton id='d2'       label='2' onActionPerformed='digit(2)' styleClass='digit'/></cell>
      <cell><JButton id='d3'       label='3' onActionPerformed='digit(3)' styleClass='digit'/></cell>
      <cell><JButton id='multiply' label='x' onActionPerformed='multiply()' styleClass='operator'/></cell>
    </row>

    <row>
      <cell><JButton id='d0'     label='0' onActionPerformed='digit(0)' styleClass='digit'/></cell>
      <cell><JButton id='sign'   label='+/-' onActionPerformed='toggleSign()' styleClass='operator'/></cell>
      <cell><JButton id='dot'    label='.' onActionPerformed='dot()' styleClass='digit'/></cell>
      <cell><JButton id='divide' label='&#x00F7;' onActionPerformed='divide()' styleClass='operator'/></cell>
    </row>
  </Table>
</Application>

The code that does all of the math is in a separate file, Calculator.script, which isn't relevant here. Hopefully this example is pretty easy to read even if you have never seen JAXX before. It's just creating a label, a bunch of buttons, and sticking them into a table. As it appears above, there is no style information at all -- no in-line styles, no stylesheet. Just plain raw components:

Clearly, it needs some work. Let's start by adding a style tag:

<Application title='Calculator'>
  <style source='Calculator.css'/>
  <script source='Calculator.script'/>
...
</Application>

Now we need to create the Calculator.css file:

Application {
    lookAndFeel: system;
}

#display {
    background: #BCE5AD;
    opaque: true;
    horizontalAlignment: right;
    border: {BorderFactory.createBevelBorder(BevelBorder.LOWERED)};
    font-size: 22;
    font-weight: bold;
}

This stylesheet switches the look and feel to "system" (Microsoft Windows on this particular machine) and styles the component named "display" to have a background, a border, and different font settings. Here's what it looks like now:

We're headed in the right direction now, but it needs more. Perhaps a bit of color, maybe some bigger buttons, different font...

Application {
    lookAndFeel: system;
}

#table {
    border: {BorderFactory.createEmptyBorder(4, 4, 4, 4)};
    font-face: "Trebuchet MS";
}

#display {
    background: #BCE5AD;
    opaque: true;
    horizontalAlignment: right;
    border: {BorderFactory.createBevelBorder(BevelBorder.LOWERED)};
    font-size: 22;
    font-weight: bold;
}

JButton {
    font-size: 18;
    width: 60;
    height: 35;
}

JButton.digit {
    foreground: blue;
}

JButton#dot {
    font-size: 20;
}

JButton.operator {
    font-size: 18;
    foreground: #009900;
}

JButton.clear {
    foreground: red;
}

This stylesheet controls the buttons based on their styleClass attributes, and in one case id, in order to style them by logical groupings. Here is the calculator with the final stylesheet in place:

Compare the newly styled appearance against the unstyled appearance above. Okay, so it's not Monet, but I'm not a UI designer either. The fact that I could hand this program and this stylesheet to a UI designer and say "please make this prettier" -- and that the UI designer would actually be able to without my help -- is really exciting to me. I think CSS stylesheets and Swing are a perfect marriage, and I'm pleased with how the combination has turned out in JAXX.

If you want to compile and run these examples yourself, you will need to download JAXX from http://www.jaxxframework.org/.

This work is licensed under a Creative Commons License.