Available for some time in various beta releases, Sun released this week a final version of Java SE Update 10, a desktop-focused version of the Java SE runtime.
In this interview with Artima, Danny Coward, chief architect of Java SE and Sun's Java Runtime, discusses the key new features in the latest Java update:
This is an update to the Java runtime environment on the desktop. The driving factor around this [update] is to make the runtime better-suited for rich Internet applications. We've spent many years building out the [Java] platform for enterprise development: Java SE is the basis for the Java EE technologies, and also for more traditional-looking Swing GUI applications on the desktop.
Over the last few years, the amount of rich-client content has started to eclipse the amount of enterprise content around the world. It was time for us to look into how we could make the runtime for the desktop much lighter-weight, quicker to download, quicker to start, and something that would make the content more modern looking. Those are the main desires that formed the basis of Java 6 Update 10.
The starting point for these changes is when consumers first download and install the JRE. We have a technology, Java Kernel, that streamlines and speeds up the download and install process. As we've added more and more features to Java SE over the years, the runtime has become bigger and bigger, until it has gotten up to about 14.5MB [in download size]. Even over a reasonable Internet connection, that's a noticeable download. In addition to download, unpacking that amount of code takes a significant time as well.
With Java Kernel, we've slimmed down that initial download from 14.5MB to about 4.5MB. In the Java Kernel, you have a stripped-down Java VM, with just the barebones features you need to run simple Java code, and just enough of the core APIs in Java SE to run a Swing application. Our judgement was that most consumer applications are Swing-based applications, and there are lots of features in the Java SE platform they don't typically use, such as CORBA or RMI. So this initial download allows a Swing application to start up really quickly, and then, in parallel, the rest of the platform is lazily downloaded. By the end of the process, you'll have the whole JRE, but that first piece installs much faster and starts up much quicker.
Another area that the JRE had fallen behind in terms of running consumer content is Java QuickStarter. It's all about starting applets and applications very quickly. When we analyzed why some applets took many seconds to start, most of the time was spent touching the files of the JRE, and moving them into the disk cache. Now we preemptively do that so the files are ready and, as a result, applets start in a much more reasonable time. Obviously, the actual time an applet takes to start depends on the applet, but most consumer-focused applets we tested are in the sub-2-second start-up range, which is acceptable for consumer content.
Next, we made modifications to the Java Plug-in architecture. This is the software that integrates the JRE within the browser, and it's responsible for starting up the JRE, starting up the applet, and for the all communication between an applet and a Web page. Prior to this release, the plug-in and applets ran in the same process as the browser. That was fine, but it if you had a rouge applet that consumed a lot of memory, that affected the browser's performance. Or, if you had an applet that had to do some very intensive work at start-up, users were not able to use the browser while that was going on because the applet consumed all the resources of the browser.
With the new plug-in architecture, the process that runs the new plug-in spawns off a new JVM process to run the applet. As a result, the browser is running in one process, and the applet is running in another process. This is a much more robust and scaleable architecture for running applets in a Web page.
The new Java Plug-in architecture allows some neat deployment tricks. If you navigate to a Web page with an applet in it, you can invite the consumer to drag that applet out of the Web page, and onto the desktop. The applet is then a free-floating window on the desktop, and still continues to run even as you're dragging it out of the Web page. Because it's running in a separate process, you can shut down the browser, and the applet keeps running. If you then close the applet, you'll be prompted with a choice of whether you want to install the applet onto the desktop. So the next time you want to run the applet, you don't need the browser at all. This enables developers to stick an applet in a Web page, and if consumers like that applet, they can just pull the applet onto their desktop and use it again later, without even having to be connected to the Internet. This is something other rich-client technologies can't do at the moment.
The new plug-in also eliminates lots of the differences between applets and desktop Java applications. Applications that are deployed via JNLP had access to JNLP-specific APIs and JNLP services. Now these APIs are also available to Java applets as well, because we have a common deployment infrastructure. Applets can also see all the SE APIs that desktop applications have access to.
Obviously, applet lifecycles are unique to applets, such as init(), start(), stop(), and destroy(), that's different for a desktop application. Applets also have access to the Web page in which they are embedded in: using the DOM API, they can interrogate their surroundings, which is a Web page. When an applet is dragged onto the desktop and installed as a local application, the JNLP framework still supports the applet lifecycle. But that applet no longer has access to a Web page environment, since the applet is no longer running in a Web page.
The final piece is that we made existing Java applets and applications look better. We did that in two ways. On Windows Vista, instead of rendering the 2D graphics in the Java layer, which works fine, but is an extra layer on top of the OS, we now render those graphics natively, using the DirectD API, which is part of Vista. For applications that heavily use animations, translucency, and shading, rotations, all those features that are becoming much more common, they're all done natively. Consequently, the rendering is much quicker, and much smoother than you could ever achieve by rendering it at a higher level in the stack.
Many developers when they create a client application, that want that application to look as if it's a native application. We've worked hard over the years to make sure that Java applications have kept up-to-date with the look-and-feels of the native OSs. But there are also developers who like to develop an application that has a characteristic look which is the same regardless of the platform you're running it on. We've had the Swing Metal cross-platform look-and-feel, but it was time for an update. We we've added a new look-and-feel called Nimbus, which is rendered using vector-scalable graphics. That means that Nimbus looks great at any magnification, and is infinitely scalable. It also helps keep the Nimbus very small—it's only about 56KB.
These technologies are currently available only on Windows. We have to decide where to allocate our priorities, and what we see is that the majority of consumers are on the Windows platform, because that's by far the pre-dominant platform. In the OpenJDK project, there are people who ported these features to other, more niche platforms. As well, Apple has now completed its support for Java SE 6 on the Mac platform. I'm not sure what of these new features will eventually become available on the Mac, but some may eventually be. Of course, Apple does its own work to accelerate graphics on OS X, including graphics for Java applications, and we work very closely with them.
Previous Topic
