Sun's main announcements at JavaOne 2007 centered around a renewed interest in client-side Java. Among the more interesting facets of that interest is a new focus on making client-side applications easier to deploy to consumers.

A key piece of that new focus is a client-focused JRE release, the Consumer JRE. This JRE version, according to Sun's Chet Haase and Ethan Nicholas, will be available in an update to JRE 6, the current Java runtime release.

Haase, who spoke to Artima about new Swing features prior to JavaOne, described the key features of the Consumer JRE in a blog post, Consumer JRE: Leaner, Meaner Java. There are three interesting ideas in Haase post:

This is one of the most serious holdups 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...

It is not unusual to see an applet take 5-10 seconds, or even longer, to start. While such a delay might be acceptable for a large desktop application, such as an IDE that's going to run all day after cranking it up in the morning, startup times like this for applets are unacceptable and limit applet viability for lightweight consumer content.

As Haase has mentioned elsewhere, this problem is an effect of the JRE consisting of a large number of large files that all have to be loaded into disk cache before a JVM can launch:

The files that make up the complete Java platform are, well, large. For example, a recent version of Java SE 6 that I have sports an rt.jar file of over 40 MB alone. If you add in the various other jarfiles, 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...

But we can pre-load at some earlier time, such as Windows boot or login time. And we can keep the pages warm in the disk cache as machine and memory conditions allow...

Note that this approach is not the same as running a full Java VM. 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. Our approach will work just with the disk cache itself, allowing the operating system to use the system memory and disk cache as it sees fit.

Java Kernel: This project will allow a new JRE installation to download incrementally, starting with just the pieces required by an application:

The big idea behind Java Kernel is to take the sub-setting 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.

Deployment Toolkit: The only viable way today to auto-install the JRE is via the ActiveX control available since JDK 1.4. That, however, works only in IE. To remedy this situation, the Consumer JRE will include a tool that works with JavaScript as well:

There is still a browser plugin that provides a high level of detection, installation, and launching support, but now that plugin has been ported to also work in Firefox on Windows. But if the plugins can not be used, there is also a JavaScript solution, hosted primarly on Sun's site with a small piece of code that runs on the deployer's site, that can do far more than the current manual approach.

Haase also mentions a port of the initial work Sun invested in creating an OpenGL-based Java2D rendering pipeline to Microsoft's Direct3D, promising both stability and performance, at least on Windows.What do you think of the Consumer JRE? Do you think it will help revitalize client-side Java development?