jmod comments

[Jonathan Gibbons]

Roger,

Thank you for your $0.02.

It is not clear that it is an easier or better to compile into a module 
than it is to compile into a jar file, and that is something that 
traditionally, javac has not done. javac has enough options now, and I'm 
not sure how well we could graft on the additional extra options for 
creating and updating module libraries.  That all being said, this is 
something that others could experiment with, because the sort of 
features you describe could likely be provided by a suitable 
JavaFileManager, capable of writing into a module library, and exercised 
through the JSR 199 API.

I know Ant does not meet with universal acclaim, but I think the idea of 
having tools using a single JVM able to invoke javac and then invoke 
module tools like jmod is a good one. I think that gives a useful 
flexibility (modularity?).   That all being said, if there are 
reasonable opportunities to make easy cases easier, I am open to 
suggestions.

As for module boundaries, the module boundaries being proposed for JDK 
are very fine grain [*], and I do not think they are amenable to a 
restructuring of the source tree -- especially when classes in the same 
package are separated into different modules. I think for newer code, it 
will be easier to have the source structure mirror the module structure, 
but for large legacy code bases that are being retroactively broken into 
fine grain modules, I am not so sure the same will apply.

[*] In langtools, the proposed structure seemed to be one module for the 
main set of classes, with additional modules for each tools main class, 
with some other classes being pulled out and treated specially.  I 
forget where public API like javax.tools and javax.lang.model ended up.  
Mandy may have changed the assignment since I looked in detail.   For 
langtools, it has also traditionally been the case that langtools/ repo 
provides its classes, but the jdk/ build determines the packaging, 
deciding which classes go in rt.jar and tools.jar.  OK, rt.jar and 
tools.jar are going away, but the structure of the build is still such 
that module packaging is determined in the jdk/ repo build.

-- Jon


Roger Riggs wrote:
> 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 
>>
>