JRE provisioning

Ethan Nicholas is experimenting with a browser edition of Java. I've also been thinking about JRE provisioning: installing the core of a Java runtime and having it download and install additional pieces as required.

To work well, this needs a modularised JRE - a JRE which has been broken into 'modules' with well-defined dependencies. This is happening in Apache Harmony¹ where modules are defined using OSGi metadata, as in this example of the NIO module:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Harmony NIO
Bundle-SymbolicName:org.apache.harmony.nio
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Import-Package:java.io, java.lang, java.lang.ref, java.net,
java.nio.charset, java.security, java.util,…
Export-Package:java.nio, java.nio.channels,
java.nio.channels.spi, org.apache.harmony.nio

Then a provisioning mechanism is needed. In OSGi, dependencies are usually resolved statically. Before a module is executed, each of its static dependencies is resolved to some module which satisfies the dependency. For provisioning, dynamic dependencies are required and, fortunately, OSGi supports these. During class loading the relevant dynamic dependency, such as the need for a particular package, is resolved. This suits provisioning nicely: during class loading if the imported package is not installed, the corresponding module can be downloaded and installed and then the dependency can be resolved. Needs a bit of work, but not very much.

In addition to the basic mechanism, the Java standard may need tweaking to define what is supposed to happen when provisioning fails because of network errors.

Finally, for best results, the JRE modules would need carefully layering to ensure the necessary machinery, such as network access, is available before the first download is initiated and to avoid dragging in essentially unnecessary modules too early. This could take a lot of work since existing JREs aren't layered this way. However, it should be possible to demonstrate reasonable results without having to rework the JRE modules significantly.

It'll be interesting to see how Ethan gets on. Can he do without a proper module system or will he, for example, try to use the new Java module system, JSR 277, which is also planned for Java 7?

Footnotes:

1. For more detail, see this presentation, slide 23 and following.