Skip to main content

Time the Avenger

Posted by editor on July 26, 2006 at 6:39 AM PDT

How long will users wait for Java?

One hot topic that has emerged again in the Javasphere is the idea of the "modular JRE", one which splits rt.jar into smaller pieces that can be downloaded independently. The idea here is that for users who don't need all of the JRE, the time required to download and install (or update) Java can be reduced by not sending pieces that are not needed now. To wit: headless servers will probably never need Swing or the AWT, while desktops can probably go without JMX, and could probably skip JDBC, XML parsing, and crypto until it's needed by specific apps.

Evan Summers takes this up in his blog Firing up the Browser Plugin, a response of sorts both to David Van Couvering's Working from home, OSCON, AJAX, Groovy and global warming and Ethan Nicholas' Java 2 Browser Edition. He responds to Ethan's concerns about Java in the browser, specifically that the JRE is unrealistically big to download at 7 MB, it doesn't start as fast as other plug-ins. He notes that 90% of computers already ship with Java installed, but admits that the download and install is perceived as a problem, and moves onto the startup time challenge.

OpenOffice addressed its huge startup time in part by pre-loading itself (as a background process). Maybe the Java Plugin could do the same, and feature an optimised ClassLoader that does some preloading of the most commonly used classes from standard libraries.


So I want a Java Plugin with (a) the option to get loaded when the browser starts, and (b) with a class cache for preloading standard libraries. There could be different cache size settings, eg. a "cold" one for startup eg. 0 to 16Mb, a "warmer" one to kick in when the first applet tag is seen in a web page, and a "hot" one for after an applet has been launched, eg. 0 to 32Mb. Considering that the Java5 rt.jar is 32Mb uncompressed, and 7Mb compressed. In practice, i guess you would have "cache size" and then "performance" settings of "low", "medium" and "high.

Now here's something that Even doesn't wonder about, but I will, since it's been on my mind lately. Think about this idea of preloading standard libraries, so they'll be ready when you hit an applet. Evan's presumably thinking of loading from disk, but what if they were loaded from the network and just locally cached instead? Wouldn't this also solve some of the installation complaints? Ship a barebones JRE that primarily knows how to get more classes (one of the great things about Jini is its remote classloading; repurpose it!), load those jars over the net as necessary, and cache them locally. That way, the end-user never downloads or installs more than they need, and as Evan suggests, the most-used classes can be pre-loaded, from network or cache, and will be ready to go when needed. Maybe that can figure into the re-thinking of JAR's, versioning, and dependencies that was promised back at JavaOne 2005...

Also in today's Weblogs, John O'Conner sees some value in

Scripting on the Java Desktop:
"Forget about web applications for a moment. I've discovered that desktop applications can use scripting too."

Meanwhile, David Van Couvering has been on a
Portland walkabout, which he says is about
"getting some quiet time before the OSCON melee starts tomorrow."

In Java Today, blogger Roger Kitain again delves into JBoss Seam in Seam (FCS) On GlassFish: "So far we've seen how we can get Seam running on GlassFish with Hibernate Persistence and Java Persistence. Modifications were needed to the Seam core classes as well as the application classes. Fortunately, JBoss has made the modifications to their core classes in time for their Seam FCS release. In this entry we'll outline the steps to get the Seam FCS release up and running on GlassFish with Java Persistence."

Want to get started with Sun Grid but don't know how? The article Sun Grid Visual Quickstart offers a sort of "hello world" for the grid: "This is a guide to help you understand how to run your applications on the Sun Grid. We'll start with an absolutely simple one-class Java application. From there we'll write the necessary scripts to run it on the Sun Grid. Once the application is built and packaged, we'll go through a very visual walk through of uploading and executing the application on Sun Grid."

Kunal Jaggi takes a look at what distinguishes Apache's open source Java EE platform in What Is Geronimo. "Geronimo fills a need that other application servers do not. With Geronimo, components can be easily integrated. Its key aim is to support custom builds, geared to the needs of specific applications. Geronimo offers choices." In the article, Kunal talks about what makes Geronimo unique, and helps you get started coding, deploying, and testing your first app on Geronimo.

One file format that has defied easy handling by Java is PDF, as discussed in the thread Re: Open source Java2D PDF viewer component?, which we feature as part of today's Forums.
rbair writes:
"I wish there were an "A+" solution too. Every option that has been mentioned so far has drawbacks. The Adobe component is _really_ old. The UI shows it (ugly!). The best I've found so far is to use the Adobe plugin + embedded browser. There are three problems with this approach that come to mind. First, embedding a browser and opening the Acrobat plugin isn't going to be lite on memory. Second, if the Acrobat plugin crashes, say goodbye (and this has happened to me in simple test apps I've written more than once). Third, it's like raising the white flag. I know this is a huge issue for some people (myself included), but I'm afraid that at the moment it is outside SwingLabs control. If an external contributor wanted to pick this up and run with it, please let me know! Anybody in need of a Master's thesis?"

tneward is trying to build Mustang and finds himself asking
What is SLASH_JAVA, anyway?
"Trying to build on a Windows XP box, and I can't quite figure out what to set ALT_SLASH_JAVA to in order to get away from the "make sanity" warnings about it. While we're at it, what should ALT_JDK_IMPORT_PATH point to, anyway? I know it's supposed to point to a good JDK instance, but where, exactly? The root of the JDK itself, the root of the JRE, someplace inside those paths, ....?"

In today's
News Headlines

Registered users can submit news items for the href=""> News Page using our
news submission
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href=""> News RSS

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

How long will users wait for Java?