Roger.Riggs at Oracle.com
Sun Apr 4 18:26:46 PDT 2010
I would think it would be most useful of Javac could be given a module
including lists of classes, etc. and directly compile the classes and
into the Library. JavaC already knows the structure and semantics of
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
or update the contents of an existing module. Regardless of the update
the snapshot of bindings between classes and modules would need to be
And it would address the incremental compilation problem as well if
only the classes that have changed.
btw, assuming that the module boundaries make sense and are sustainable
it would think that it would beneficial to rearrange the OpenJDK source
to match the module structure at some point so maybe the current awkwardness
is a growing pain and short lived.
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. 
> 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, 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  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
> 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.
More information about the jigsaw-dev