The Modular Java Platform

The story so far The JDK is big—and so we ought to modularize it. Doing so would allow us to improve the key performance metrics of download size, startup time, and memory footprint.

Java libraries and applications can also benefit from modularization. Truly modular Java components could leverage the performance-improvement techniques applicable to the JDK itself, and also be easy to publish as familiar native packages for many operating systems.

Connecting the dots Given a modularized JDK and a modularized application, the next logical step is to arrange for the application’s modules to declare dependences upon just the JDK modules that it requires.

This would enable a capable native package manager such as rpm or apt to download and install just the JDK modules that are needed to run the application.

This would also enable a next-generation Java Kernel to download, initially, just the application and JDK modules needed to start the application. Once the application has started up then the Kernel would download additional modules on demand, as they’re requested by the program; in the meantime it would trickle-download all the remaining modules in the background.

JDK != Java Platform The problem with this scenario is that it would leave applications, and any libraries upon which they depend, tightly bound to the JDK and hence not portable in the sense of the “write once, run anywhere” ideal. The JDK is, after all, just one implementation among many of the Java SE Platform.

Omitting some dots Small devices are becoming faster all the time, with many of them now quite capable of running a HotSpot virtual machine and the core classes of the JDK. Their persistent-storage capacities, however, are growing at a slower rate.

Manufacturers of embedded devices and high-end cell phones generally aren’t willing to increase the cost of a product in order to pay for the memory required to carry around libraries that are never actually used by applications. With a modular JDK they’d have the option of carrying just the modules that will be used by expected applications, and with modular applications they’d be able to verify, at either build or install time, the availability of the necessary JDK modules.

The monolithic Java Platform The further problem with this second scenario is that no proper subset of a modular JDK is an implementation of the Java SE Platform, since the Platform itself is monolithic and indivisible. Put another way, no such subset can be tested for conformance against any particular Java SE Platform Specification, since the Specification itself is monolithic and indivisible.

Meta-modularization By now the solution to the above two problems is, no doubt, obvious: The Java SE Platform should be modularized.

This process could start with the definition of an abstract “Java SE” module whose version number would be that of the Java SE Platform Specification that defines it. The content of that specification would, as usual, be determined by the Expert Group for the corresponding Java SE Platform JSR under the auspices of the Java Community Process.

The primary module of the JDK—which would presumably be an aggregation of the concrete modules comprising the JDK—could then be amended to declare that it implements the Java SE module, much as a Java class can declare that it implements an interface. Similar adjustments could be made to other Platform implementations.

Once this is done then a modularized application could declare that it depends upon a specific version of the SE Platform—but not upon any particular implementation thereof. At runtime it would be up to the underlying module system to locate a Platform implementation capable of fulfilling this abstract requirement.

Divide and conquer To finish addressing the two problems described above, the next version of the Java SE Platform Specification could define specific common subsets—or Profiles—of the Platform. There could be, e.g., Profiles for minimal headless applications, for simple RIA-style desktop applications, for richer desktop applications, for server applications, and for other configurations at various points in between. The Java Compatibility Kit would correspondingly be divided into subsets of tests for each Profile.

Each Profile would be represented by its own abstract module. For each of the Profiles that it supports, a conforming implementation of the Platform would be required to include a concrete module that implements the corresponding abstract module.

Once all this is done then a modularized application could declare that it depends upon a specific versioned Profile of the Platform. An application delivered as familiar native packages, or via a Java-Kernel-like mechanism, would no longer be bound to any particular Platform implementation. A small device, finally, could include just the subsets of the Platform that are required by the applications expected to run upon it—yet still claim conformance to the Platform Specification.

Now wouldn’t that be truly and completely cool?

The only remaining question is: How do we get there?

Comments:

I'd go a step further:

Why do you need to sub-divide JavaSE or define profiles? All you need is a Java Kernel-like system that will download missing modules on demand.

I don't think it should download any modules in the background (to complete "the rest of JavaSE"). It should only download modules that are explicitly requested.

Modules would develop at totally independent rates. Sun would then "tag" specific versions much like you can do with CVS/SVN today and say "Java7 consists of: Swing 1.3, AWT 1.6, Corba 6.5, etc..." In other words "this is the configuration we tested against". Developers can then choose to either deploy against these specific versions or other versions if they so wish.

JavaSE the platform should simply guarantee that all modules are \*reachable\* at any given time, not that they must actually be available on the local machine. The JavaSE "profile" should simply tag specific module versions as I mentioned above. Users would be free to use Java core modules or 3rd-party ones as they wish (and any versions thereof).

Posted by Gili on December 02, 2008 at 12:14 PM PST #

Oh, no! My nightmares just came back! I have visions of fragmented Java ME with zillions of different modules, JSRs. A vision where each device has its own particular set of JSRs installed, an no device has the exact same subset. This is basically the worst that can happen.

Please, PLEASE, spare me this. A monolithic JRE is basically the only guarantee to have a true code once, run anywhere.

So no, the Java SE platform must stay THE java SE platform, not one of many profiles. Splitting it in profiles is just asking for trouble, IMO.

Posted by guest on December 03, 2008 at 12:41 PM PST #

Java ME is fragmented because:

1) Different phones have different capabilities (this is not the case for JavaSE)

2) The TCK is weaker than it is on JavaSE

I fail to see how modularizing the platform will have any impact similar to JavaME.

We already have some form of fragmentation (if you can call it that) on JavaSE in the form of 3rd-party libraries. For example, there are 5 different XML parser libraries, 30+ different webapp frameworks, etc. This isn't necessarily a bad thing or anything that a monolithic architecture helps or discourages one way or another.

Posted by Gili on December 03, 2008 at 12:47 PM PST #

Those 3rd party libraries are no problem, you can include them with your application if you need them.
If however you can't even rely on core language features being installed on a client machine you're in deep trouble, and that's what a "modular JVM" would lead to.
It would also be disastrous for startup time, as it increases the amount of things that need to be loaded from configuration files and determined at runtime rather than being hardcoded somewhere.

The only things that should be "modularised" out of the core distribution are those useless additions put in in JDK 6, like JavaDB, embedded HTTP servers, and rubbish like that.
Or better yet, abandon 6 and go back to 1.5.
That version was stable, performed well, and didn't have too much junk in it.

Posted by J.T. Wenting on December 03, 2008 at 03:41 PM PST #

The only way this could lead to longer start up times is if you needed a module that wasn't there, so the system has to download it first. That would happen once. It could easily be part of the installation process.

Posted by Jon Strayer on December 08, 2008 at 12:51 AM PST #

Post a Comment:
Comments are closed for this entry.
About

This blog has moved to http://mreinhold.org/blog. <script>var p = window.location.pathname.split('/'); var n = p[p.length - 1].replace(/_/g,'-'); if (n != "301") window.location = "http://mreinhold.org/blog/" + n;</script>

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll

No bookmarks in folder

Feeds
RSS Atom