jmod comments

[Roger Riggs]

Hi Jon,

I would think it would be most useful of Javac could be given a module 
definition
including lists of classes, etc. and directly compile the classes and 
insert them
into the Library.  JavaC already knows the structure and semantics of 
modules
and so it should not be a stretch to see that it could directly generate 
into the library.
Since it would be given version information it can correctly create a 
new module
or update the contents of an existing module.  Regardless of the update 
mechanism
the snapshot of bindings between classes and modules would need to be 
re-evaluated.

And it would address the incremental compilation problem as well if 
javac compiles
only the classes that have changed.

btw, assuming that the module boundaries make sense and are sustainable 
then
it would think that it would beneficial to rearrange the OpenJDK source 
structure
to match the module structure at some point so maybe the current awkwardness
is a growing pain and short lived.

$.02, Roger




Jonathan Gibbons wrote:
> 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 
>