Library delegation, the big JDK module, and modular launching
mr at sun.com
Thu May 14 14:55:29 PDT 2009
I just flushed my Mercurial patch queues into the Jigsaw forest.
Herewith a summary of what's new.
A module library can now have a parent library. Each module in the
parent that is not also present in the child appears to be in the
child, recursively. The Library find and read methods will consider
the parent if something is not found in the child, but configuration
operations only affect the child.
In a related change I removed the Library.visitModules method, which
wasn't much used and didn't make much sense in the presence of library
delegation. There's instead now a gatherModuleIds method which will
return all module ids from a library as well as its parent, if any.
When creating a library with the jmod command you can specify its
parent with the -P option. If you don't use -P then the parent will
default to the JDK module. You can use -N to specify a null parent.
(Side note: I figured all along that we'd need this; I was trying to
defer it to later but it greatly simplifies testing, so I did it now.)
The big JDK module
At last! The final phase of the build now creates the jdk at 7-ea module
in build/lib/modules, by copying files from build/classes. Classes in
this module are loaded by a specialized Jigsaw loader which invokes the
VM's bootstrap loader via the new j.l.ClassLoader.findBootClass method.
During module configuration, if a module doesn't declare a dependence
upon a "jdk" or "jdk.*" module then a dependence upon "jdk at 7-ea" is
automagically added. (Hmm, perhaps we could call this the "Miranda"
module ...) This is temporary: Ultimately the compiler should add such
default dependences, and they should be upon the more abstract "java at 7"
module, which the jdk module would provide, but this works for now.
This changeset also includes some basic performance work, to cache
ModuleId hash codes and to use identity rather than value equality in
the Context and Configuration classes.
Modular launch sequence
This was the fun one. I've hacked the launcher (src/share/bin/java.c)
and related logic in j.l.ClassLoader and elsewhere to be able to launch
a root module by name, invoking the main method of the class declared
in its module-info file. To launch a module you just say:
$ java [-L <module-library>] -m <module-name>
When the JRE is started up this way the "system" class loader is just
the Jigsaw loader for the named module, which -- due to the default
library parent and dependence on the jdk at 7-ea module -- delegates to
the Jigsaw boot loader to find classes formerly found in rt.jar.
(I do have to admit that routing around the old sun.misc.Launcher class
and the innate complexity of URLClassLoader and friends was a distinct
Of course I've also upgraded all the runtime code and tests to use Jon's
new module-path-aware javac (thanks!).
(Side note: I heavily used Mercurial patch queues for the first time
while working on this set of changes. Highly recommended!)
My next task will be to simplify the Resolver interface for Jon, and then
it'll be time to start <a href="knives-sharpening.ogg">slicing up</a> the
big JDK module.
More information about the jigsaw-dev