|By Chet Haase, May 2007|
Recently, Thorsten Laux and I presented the session "Desktop Java Technology Today" (TS-3160) at the 2007 JavaOne conference about where we are and where we're going in Desktop Java. We covered the download numbers (awesome!), statistics on how many PCs have the Java platform installed (excellent!), and highlighted various desktop applications that use our Desktop Java technologies (fantastic!). We then quickly covered some of the larger features that were implemented in the recent Java SE 6 release. Check out the various blogs and articles on the topic for more on those features. We concluded with the technical diagram in Figure 1.
Clearly, the combination of growing ubiquity, power of the platform, and features in the latest release means that the team is done, right?
Well, perhaps not. Some issues still need to be addressed, as you can see in Figure 2.
The reality is that there are several outstanding issues with Java technology as a consumer desktop platform, which need to be fixed soon in order to make the platform competitive now and in the future.
The good news is that the Desktop team is, in fact, aware of these issues. The better news is that the problems are being worked on. The best news is that the team is close to solutions and intends to deliver them as an update to the Java SE 6 release, in a release called the Consumer JRE
The Consumer JRE consists of several important pieces of functionality, some of which are depicted in detail in Figure 2. One of the keys to getting this out quickly as an update to the Java SE 6 release is to make only those changes that do not affect the APIs. For example, the team members can add functionality to make startup faster without affecting the APIs or functionality that an application is using. But they cannot add a new animation API in an update release. Fortunately, this constraint is not too cumbersome because the major problems to solve now are below the level of API changes and are thus completely suitable for this release.
Here are the main items that the Desktop team is shooting for in this release:
Quickstarter will probably be the most popular item in the mix, making the launch of any Java application or applet much faster. This is one of the most serious delays to further applet development and deployment today, as the launch of the first applet in a browser can take several seconds. Quickstarter will cut down the launch time significantly, vastly improving the first-launch experience for consumer Java applications.
There are actually two issues with Java application startup: warm start and cold start. Warm start is the time that it takes for a Java application to start when you have recently run Java technology on your system. Cold start, on the other hand, refers to the time that it takes to launch the first Java application after a fresh reboot.
Warm start times are reasonable these days, due to plenty of continuing work on improving performance, in addition to machines simply getting faster over Java technology's lifetime. A simple application or applet will take one to two seconds to start up, which is similar to the time to load standard web pages, and it is within an acceptable range for the user.
Cold start, on the other hand, continues to take an unreasonably large amount of time. It is not unusual to see an applet take five to 10 seconds, or even longer, to start. Although such a delay might be acceptable for a large desktop application, such as an integrated development environment (IDE) that's going to run all day after the developer starts it in the morning, startup times like this for applets are unacceptable and limit applet viability for lightweight consumer content.
The problem turns out to be at the operating system (OS) level. This is not to shrug off a difficult problem but to indicate that the Java platform is facing some basic physical constraints at the OS and hardware level that the team must work within. In particular, the files that make up the complete Java platform are large. For example, a recent version of Java SE 6 sports an
rt.jar file of over 40 MB alone. If you add in the various other JAR files, native libraries, and resource files that get touched at startup, regardless of any application-specific code, that's a lot of data that has to be read in.
At the OS level, this means that all of these megabytes -- or rather, tens of megabytes -- have to be read from disk, which is a very slow operation. To be more exact, it's the seek time of the disk that's the killer. Reading large files sequentially is relatively fast, but seeking the actual bits needed is not. So even though the platform needs only a small fraction of the data in these large files for any particular application, this seeking all over within the files creates a great deal of disk activity. No wonder it takes so long for a Java application to start up, because the platform is dependent upon the speed of such an inherently slow operation to begin with.
The reason that warm start is so much faster is that once some data has been read off the disk, the OS places it in the disk cache. The next time that memory is needed, the OS can retrieve it from the disk cache, which is a significantly faster operation.
The fix, then, is to take advantage of the disk cache to make sure that the memory pages on disk that the platform must read at startup have already been loaded before the platform needs them. How is this task accomplished? The platform cannot magically preload the pages just prior to launching. Unfortunately, the Java virtual machine (JVM) * currently lacks the ability to see into the future to detect when the user will be launching a Java application. (The Desktop team would love to have this feature in the future, but it is not yet present.) But the platform can preload at some earlier time, such as Windows boot or login time. And the pages can stay warm in the disk cache as machine and memory conditions allow.
Note that this approach is not the same as running a full JVM. That approach would solve some of the same problems but in a less efficient manner, locking up the memory in a less OS-friendly way. The Quickstarter approach will work just with the disk cache itself, allowing the OS to use the system memory and disk cache as it sees fit.
The Java Kernel project addresses the time-to-launch problem for users who do not have the proper JRE installed. For example, if your application requires users to have Java SE 6, then if they do not currently have that release, they must install it prior to launching the application. Given the size of the JRE and depending on the amount of bandwidth available to the user, the download and installation time can take anywhere from tens of seconds to tens of minutes. The Java Kernel project will cut this time down dramatically, allowing the application to install just what it needs to launch itself.
Just like Quickstarter, the main issue behind the time that download and installation takes is size: The Java platform is large, even when zipped and Pack200 compressed, and there are physical realities to bandwidth and bit copying that cannot yet be overcome. Of course, one solution would be simply to shrink the platform, but in a world where Java technology is backward compatible and any Java application compiled to a particular release can expect to run on any release of that version or later, the idea of breaking up the Java runtime into subsets simply does not work.
The big idea behind Java Kernel is to take the subsetting approach, breaking up the monolithic Java platform into discrete chunks of functionality that get downloaded and installed according to what any specific application needs, but to then stream down the rest of the platform in the background.
Taking this approach ensures that an application that installs the Java Kernel will have the functionality that it needs with a much faster install and startup experience. In addition, any future Java application can still take advantage of the entire Java platform for that release, because the Java Kernel installation process will ensure that all of the proper bits get installed eventually.
The basic workings of the Java Kernel are as follows:
Class not foundexception culprits as needed.
The project is very much in development, but initial results show that it is possible to cut the download size by over 60 percent for midsized Swing applications. For example, Figure 3 shows some very preliminary numbers for some sample applications to show how application-specific bundle sizes compare with the complete size of the JRE.
To date, the main mechanism for automatic detection of Java technology on the user's system was the ActiveX control called Auto-Install, released in J2SE 5.0. This mechanism was necessarily limited to Microsoft's Internet Explorer browser, and only if the user allowed that ActiveX control to run. Other than that, the process was quite manual and usually involved sending the user to java.com to optionally install the Java platform and hopefully return to your site.
For an example of how the current system works, check out the article " Auto-Install: Easier Launching of Java Web Start Applications."
The Deployment Toolkit project is about enabling a much more powerful and ubiquitous system to run across multiple browsers and platforms, allowing developers to detect more automatically what the user has, what to do about it, and how to launch the application when Java technology is then installed.
The installation process for a new JRE should be simpler and more user-friendly. Besides the size and time issues that Java Kernel is meant to address, users need to have a better overall experience during the installation process. Figures 4 and 5 show before-and-after views of the first installation dialog box.
The Desktop team is rewriting the default graphics pipeline on Windows to take advantage of Direct3D for performing everything from simple rectangular fills and copies, which is what you get now by default, to translucency, gradients, arbitrary transformations, and other more advanced 2D operations. Swing applications both simple and complex should benefit from much better runtime performance on Windows as a result.
Swing performs its rendering through the Java 2D API and therefore depends on the graphics rendering speed of Java 2D for fast Swing performance. In J2SE 1.4, the Java platform started accessing native hardware acceleration through DirectX on Windows but only for the basic operations of filling and copying rectangular areas and horizontal and vertical lines.
These simple primitives end up being quite important for Swing rendering, because much of the user interface (UI) is composed of these primitives, and the ability to cache the Swing back buffer as a VRAM image enables very fast double-buffering. But UIs are getting more complicated, and the ability to accelerate more advanced operations, such as translucency, antialiased text, gradients, and scaling operations, is becoming increasingly important.
The Java 2D team has continued to work on the DirectX rendering pipeline, which now has the ability to accelerate a wide variety of operations through the native Direct3D library on Windows. However, these performance improvements are not enabled by default due to a combination of speed and reliability issues. Meanwhile, the 2D team has also implemented a parallel OpenGL rendering pipeline with even more advanced capabilities, but that pipeline is also not enabled by default due to reliability issues on some platforms.
Now the Java 2D team is rewriting the DirectX pipeline to mirror the capabilities already in the OpenGL pipeline, with fixes for robustness that make it a more viable default rendering pipeline. This feature should finally be enabled by default, exposing Swing to extremely fast hardware acceleration through the graphics processor. This should enable faster performance for current Swing applications, but it will enable much more powerful Swing applications to run fast as well, even those incorporating much richer and more dynamic, animated effects in their graphical user interfaces (GUIs).
The Metal look and feel, shown in Figure 6, was good in its day.
And Ocean was a decent theme for Metal, especially given that it had to maintain backward-compatible metrics used by the UI components.
But these cross-platform look and feels are dated, and Swing applications need a more modern look. Of course, other look and feels are available, some quite good, and developers should explore those products and projects as well for possible use in applications. But in the meantime, Swing developers should have a decent look and feel in the core platform. Nimbus is that look and feel.
Figures 8 and 9 are samples of the the Nimbus look and feel so far.
For more information on the Nimbus project, check out Jasper Potts's blog.
The Consumer JRE will be an update for Java SE 6, which means that it will be available much more quickly than it would if it were part of another major release such as Java SE 7. But it's still a lot of work, and it's not done yet. The target release date for the Consumer JRE is early 2008, although the team is trying to get the work done sooner if at all possible. Given the amount and type of changes in this release, especially Java Kernel, this release will require extensive testing to make sure that it's as solid as you should expect it to be.
The team will roll out some features as they are available, so that you don't have to wait for early 2008 to get everything discussed in this article. For example, the improved installation experience should be out in update 2 of Java SE 6, which is currently set for late June 2007.
Most of these features are still very much in development, and they are thus apt to change scope or be removed from the release if the team's goals for them are not reachable. One of the main priorities for the release is getting it out to you as soon as possible, with as many of these features as are doable in that time frame. So if it looks as if any particular feature would stall the release too long, the team will have to weigh cutting or changing it in order to still keep to this tight timeline.
One thing that is very clear is that the features the team is providing are not things that would be nice to have in the future -- they are necessary pieces of functionality that developers and users want now. Keeping strict control over the timeline is as important as the functionality of any particular feature discussed in this article.
And who knows? Maybe the team will also get the chance to add other cool and powerful features along the way, as long as they do not disrupt this all-important timeline.
Watch for updates to appear as the Java SE team knows them, and stay tuned. You can look forward to a new era of consumer-enabled Desktop Java.
In the meantime, check out the slides for the relevant talks at the 2007 JavaOne conference when they become available. Some of these items were discussed at the "Desktop Java Technology Today" overview (TS-3160) that Thorsten Laux and I presented, as well as at Danny Coward's "Java SE: Present and Future" (TS-2383) session, and at Ethan Nicholas's "Easy Deployment" session (TS-3290). You can find more information by searching on these sessions in the JavaOne conference sessions page.
Java Platform, Standard Edition (Java SE 6)
Desktop Java Features in Java SE 6
JavaOne Online Technical Sessions and Labs: PDF and Multimedia
JavaOne Conference Sessions
Chet Haase's Blog
Chet Haase's Favorite Java SE 6 Features
Java Kernel: Ethan Nicholas's Blog
Nimbus Look and Feel: Jasper Potts's Blog