Most Read This Week
Java EE 5
A Light Java Runtime to Bundle with Applications
Steve Jobs once said that Java is a big heavyweight ball and chain. Good news: the ball is now optional!
By: Vitaly Mikheev
Dec. 11, 2009 06:00 PM
Java Development on Ulitzer
This is not a mere “Java gets smaller” message. Given that Project Jigsaw is emerging in JDK 7, I also offer some insights on the challenges that any implementation of modularity for the Java SE core may face, all derived from our practical experience.
“Divide and Conquer” Has Worked Out
The goal was to let Java programmers bundle a light version of the Java Runtime with their applications leaving the unused components out so as to reduce the size of the installation package. Easier said than done, but we’ve got it made in a Java spec-compliant manner and called the technology Java Runtime Slim-Down (after Project Jigsaw appeared, it’s finally got to me that we should have to call it “Project Rock breaker” or the like).
It has been proved effective for many Java applications. For GUI applications, in particular, the size of a complete installation package with bundled Java Runtime starts from 5MB. In support of this assertion, I refer you to SWTPaint, a sample program taken from the latest Eclipse SDK.
The use of Java Runtime Slim-Down yields results you won’t get with any other Java deployment tool:
Note that the GUI application in question is written in Java and uses Java SE 6. Oh, sorry! I had to mention that download size for Swing applications start from 8MB. Stirring the flame of Swing vs. SWT was by no means my intention. We prepared installation packages for a few sample applications, both Swing- and SWT-based, and you may download them from this page. If you are still in doubt, try the deployment technique yourself. This flash demo will help you get started.
There are good reasons for end users to love “all-inclusive” installation packages at reduced footprint rates, and it’s where a lightweight Java Runtime is of much help. At a larger scale, however, the lack of the JRE modularity impeded the evolution and adoption of the Java SE platform.
In Between a Rock and a Hard Place
Other JSRs were more lucky and the Java Community Process kept Java SE moving forward over the years. In 2006, I attended the Java Licensee Day event. During the Q&A part of the session devoted to then new Java SE 6, one of the licensees sharply asked: “With each release the JRE gets bigger and bigger. Our customers do not need all those new APIs. When will it stop bloating?” I then found myself thinking I agreed with him but I would rather say “Not all our customers need all those new APIs...”.
The question is how many “useful” APIs have not been approved just not to make the JRE bigger? One may ask also how many “useless” APIs have been approved and did make the JRE bigger? It’s clear that requirements of different projects vary and there is no single answer to these questions, but splitting the JRE into components could resolve these issues gracefully.
Here’s a practical example from our support records. We have customers who previously got stuck with J2SE 1.4.2 simply because the footprint of later Java versions was unacceptable for their deployment requirements. Now, after switching to the component model, they are happy users of Java SE 6.
However, I would not like to discuss the Sun’s policy on modularizing Java SE here. There were many pros and cons to consider, both technical an legal, and I fully realized some of them only when working on the Java Runtime Slim-Down technology. No shooting (in the foot)
As often happens, once we had started the design, the scope of work suddenly increased. For the truth to be told, we would not reach the goal by simply splitting the Java SE API into components and enabling the user to drop some of them. The big question was how to make the technology usable and reliable? After all, we did not want to create a thing that does not work just because the programmer removed some components too aggressively. We decided to explore the limits of this approach by interviewing those enthusiasts who pursued us for this matter. The results confirmed our suspicion – programmers are not always aware of what parts of the Java SE API are actually used in their applications. A good illustration would be the following transcript written then:
Client: I do not use that “Baggage-To-Trim” API and no longer want to carry it with my app. As you are a JVM vendor, make me happy, please.
Support Engineer: We understand you concern. Are you sure you don’t use the “Baggage-To-Trim” API?
Support Engineer:. We kindly ask you to double check it. Please run your app with java –verbose:class and inspect the log.
Client: Oops.. You surprised me! It’s proved to be used. Frankly speaking, I did not write that code where it’s used. Let me think of it.
Needless to say that we also had to think of it. In addition, Java SE components may depend on each other implicitly, via the implementing classes, and most programmers not familiar with the internals could not play safe when removing the components.
We conducted some R&D and figured out that such a technology should come with tools that help the user not shoot himself in the foot and rules which, just in case, provide the fastest recovery.
Tools and Rules
Under the covers, it’s not simply checking import dependencies as that would work poorly in terms of precision. For instance, such a simplistic analysis would not have revealed that the SWT-AWT bridge, which is part of the SWT package, is not used by the SWTPaint application mentioned above. As a result, the AWT component would be sucked in and the installation size would increase. That said, analyzer design and testing had engaged us for some time.
Does it guarantee that any deployed application will never miss the removed components? I would not bet money on it. After all, a programmer could detach some components by mistake or an application may load a plug-in that uses the Java SE API more extensively than the application itself. Here the following rule comes into play. All removed components are put into a detached package and the developer has to place it on a Web server at the URL s/he assigned when creating the installation. The Web server is considered a "safety net": should the deployed application attempt to use any of the removed components, the Java Runtime will pull the package down from the server and load the requested Java classes.
On the formal side of things, we run the Java Compatibility Kit (JCK) deployed in this mode with some and all Java SE components detached. Noteworthy is that all the tests pass.
However, it is unlikely that a download of a detached package will occur in practice, provided the developer listened to the word of wisdom from the analyzer. For example, these sample applications have been downloaded over a thousand of times since we published them in May 2007, but there was not a single download of a detached package so far.
The last note is about the splitting. We have managed to carve a kernel part of Java SE, about 4MB, that have to be bundled with any application. We could not get it smaller. We wanted to break down the whole thing into more components, each of a smaller size, but were unable to do that. In general, we could obtain better download size figures if the Java SE API implementation classes would not be so tightly coupled, full of cross-references, strongly connected, melted and fused together.
The Truth About Sun Java Kernel
You may find more details in the Java Kernel FAQ. Probably, the Java Kernel is just a preliminary step toward a solution that may appear in the future.
In parallel with the Java Kernel, Java Module System (JSR-277) was in the works, which, in particular, could address the JRE modularity problem but the deadlock between Sun and an OSGi lobby had it buried.
Finally, in the end of 2008, Project Jigsaw was announced and “Episode IV. The New Hope” commenced.
Four Challenges for Jigsaw
The problem is that the reference implementation of the Java SE API was coded without having modularity in mind. Somewhat it was a side-effect of the Java’s lazy classloading which created an illusion that a use of any class in Java code costs nothing until it’s actually executed at run time. It’s proved to be a technical debt and now is the time to pay the interest.
In practice, it means that spaghetti-like dependencies between the implementing classes are omnipresent and breaking the ties without breaking backward compatibility with previous Java versions is double tough. The danger is to create something like Apache Harmony: everything is implemented with an elegant internal architecture, samples work, but existing Java apps have issues.
Profiles All Over Again?
Need for Total Modularization
P.S. One man said that Java is a big heavyweight ball and chain. Good news: the ball is now optional! You may detach it and use module Chain only.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads