Sun's latest Java SE update features the Java Kernel, an attempt at minimizing the initial download size of the Java SE platform. While the Java kernel is a practical first step for desktop applications, the JDK developer community has been debating for some time ways to partition the entire Java SE platform into modules.

Such modularization has largely been responsible for the success of some of the largest Java projects, such as the Eclipse platform. The entire Java SE platform could benefit from a similar sort of modularization, writes Mark Reinhold, Sun's lead architect on Java SE and the upcoming Java 7 release, in a series of blog posts.

Modularization, a theme underlying the next version of Java EE as well, will be Sun's main focus in Java 7, according to Reinhold:

As a first step toward this brighter, modularized world, Sun’s primary goal in the upcoming JDK 7 release will be to modularize the JDK...

There will be other goals, to be sure—more on those later—but the modularization work will drive the release, which we hope to deliver early in 2010...

Reinhold argues that tight integration between the module system and the language are very important requirements in this effort:

It requires, in particular, a module system whose core can be implemented directly within the Java virtual machine, since otherwise the central classes of the JDK could not themselves be packaged into meaningful modules.

Modularizing the JDK—or indeed any large code base—is best done with a module system that’s tightly integrated with the Java language, since otherwise the compile-time module environment can differ dramatically from the run-time module environment and thereby make the entire job far more difficult.

In The Modular Java Platform, Reinhold reviews some of the existing Java module systems, and outlines the problems each presents:

Given a modularized JDK and a modularized application, the next logical step is to arrange for the application’s modules to declare dependencies 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.

Reinhold notes that Java SE modularization will likely be done through the Java SE 7 development process and its corresponding JCP expert groups:

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.

As part of the desire to define a suitable module framework, Reinhold writes that work on JSR 277 will be halted, while that on JSR 294 will be given renewed focus:

Owing to some of [JSR 277's] rich, non-declarative features, however, it would be impossible to implement its core functionality directly within the Java virtual machine... Sun has therefore decided to halt development of the JAM module system, and to put JSR 277 on hold until after Java SE 7...

Sun intends now to revive 294 as a separate activity, with an expanded Expert Group and greater community involvement, in support of the immediate JDK 7 modularization work as well as the larger goal of modularizing the Java SE Platform itself...

To inform the work of JSR 294, Sun will shortly propose to create Project Jigsaw within the OpenJDK Community.

Not only will this new module system integrate tightly with the Java language, but it also promises to work well with existing Java module systems, most notably OSGi:

This module system is reasonably mature, stable, and robust. Its core has even already been implemented within a Java virtual machine, namely that of Apache Harmony. OSGi is not at all integrated with the Java language, however, having been built atop the Java SE Platform rather than from within it...

This last problem can be fixed. Sun plans now to work directly with the OSGi Alliance so that a future version of the OSGi Framework may fully leverage the features of JSR 294 and thereby achieve tighter integration with the language.

What do you think of the direction Reinhold proposes?