jmod comments

[Jonathan Gibbons]

There is currently a mismatch between the way that we think the Jigsaw 
tools should be used and the way we actually use them in practice.

In particular, jmod does not well serve the needs of the primary Jigsaw 
client, the JDK itself.

jmod currently assumes that the classes are laid out neatly on disk in 
separate hierarchies for each module. That's very convenient, if that is 
actually how your classes are organized, but I venture to suggest that 
with the current fine grain module scheme, the JDK classes are never 
ever going to be laid out that way. So currently, the JDK build jumps 
through hoops moving classes around after they have been built, in order 
to satisfy the jmod input requirements. The tail is definitely wagging 
the dog here.

I'm also coming at this from a similar but different perspective: 
langtools, and the as-yet-unresolved issue of -Xbootclasspath and 
incremental builds. [1]

In langtools, we currently use -J-Xbootclasspath to avoid having to 
recompile JDK every time we edit javac or other langtools tools. In a 
Jigsaw world, the replacement would seem to be to build and use a 
private module library which has a standard JDK module library as its 
parent.  Thus, -J-Xbootclasspath gets replaced by -J-L. But that just 
defers the issue one step -- I still have to build the library, with 
jmod, meaning all the classes have to be moved around into 
module-specific hierarchies, and that just seems wrong.

It would be much better if there was a way that jmod could be given 
information about what classes belong in each module. If this was an Ant 
task[2], I would expect to see something like filesets being used to 
describe the contents of each module. In the absence of an Ant task, one 
suggestion would be to provide -include and -exclude options on the 
command line to include and exclude packages and classes. A more 
convenient suggestion would be to have jmod accept a file such as 
jdk/make/modules/modules.config [3] which is the definitive file used by 
the JDK modules build to determine which classes go in which module.

However we choose to update jmod, or a <jmod> task, it would be really 
helpful if we could compile classes in whatever way we consider usual, 
then be able to use jmod to create an incremental library containing 
just the modules that are currently being developed.

-- Jon


1. http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000719.html

2. Speaking of Ant tasks, it would be good to have one for jmod, 
especially one that recognizes that modules are up to date and do not 
need to be recreated.

3. 
http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/57a86394f749/make/modules/modules.config