[jsr294-modularity-eg] dependency declaration syntax...

[Alex Buckley]

Paul Benedict wrote:
> So if I am understanding this correctly, there is no universal module
> definition...

There is certainly a universal module definition; it's a module 
compilation unit:

   module M @ 5.0 { requires ...; provides ...; }

Such a module definition needs a module system to intrepret it - to 
parse versions, to resolve dependencies, to locate other modules, etc. 
There is a small universal module system API (see java.lang.module at 
http://cr.openjdk.java.net/~mr/jigsaw/api/) that a Java compiler and a 
JVM can call to perform this interpretation. (The API's features should 
exactly match constructs in a module compilation unit.)

The goal is to make a module definition for a given module system 
portable ('universal') across compile-time and runtime. The goal is not 
to make a module definition portable across module systems at 
compile-time, or portable across module systems at runtime.

> Let's take a concrete example like Apache Commons Lang. Right now it
> is distributed as one jar and its Manifest is enhanced with OSGi
> headers. It's possible another module system has nother requirements
> (e.g., different manifest headers, extra files), but today it all
> could be distributed as one jar.
> 
> Is JSR-294 liberal enough where module-info.java could be written and
> deployed to work with both OSGi and Jigsaw and others all at once? Are
> we going to need different distributions per module system (yuck), or
> is there a way to specify many together?

294 is very liberal, but I need to make something clear.

How a module compilation unit is represented at compile-time and runtime 
is an implementation detail. The JLS (of which 294 is ultimately a part) 
does not specify filenames, package layouts, location algorithms. That 
compilation units end in '.java'; that a public type Foo lives in 
Foo.java; that package hierarchies map to filesystem directories; that 
some concept called 'classpath' exists - none of it is normative. So the 
filename 'module-info.java' and the location of a file with this name 
(at compile-time, or the .class equivalent at runtime) is not normative.

The EG considered whether a module compilation unit should contain 
multiple sections, one per module system. The majority view was no. 
Again, 294 does not aim to make a module definition portable across 
module systems at compile-time or runtime. You pick a module system and 
stick with it through compile-time and runtime.

Now that's clear, I can say why 294 is very liberal: it doesn't care 
whether you have module-info.java/class files, and if you do, it doesn't 
care where they live. So a module can certainly be developed for both 
OSGi and Jigsaw at once:
- javac connected to Jigsaw could look for ('observe', in JLS 
terminology) a module compilation unit saying 'system jigsaw' in 
module-info.java at one location. (See [1])
- ecj connected to Equinox could look for a module compilation unit 
saying 'system osgi' in bundle-def.java at another location.

Similarly a module can be deployed for both OSGi and Jigsaw at once. 
Java compilers have enormous freedom; javac can compile a module 
compilation unit ('module M @ 5.0 { system jigsaw... }') in 
module-info.java to module-info.class while ecj can compile a similar 
module compilation unit ('module M @ 5.0 { system osgi ...}') in 
bundle-def.java to MANIFEST.MF. Then:
- A JVM may read MANIFEST.MF for pre-7 JARs and defer to the Jigsaw 
module system to interpret module-info.class for >=7 JARs.
- Another JVM may read solely MANIFEST.MF for all JARs and decide to 
deeply interpret OSGi headers, if present, by passing them to Felix.

I hope you will forgive me these rather wordy explanations, but the 
distinctions are important. To answer your questions:

Q: Is JSR-294 liberal enough where module-info.java could be written and
deployed to work with both OSGi and Jigsaw and others all at once?
A: Yes. Just spread the module compilation units out.

Q: Are we going to need different distributions per module system 
(yuck), or is there a way to specify many together?
A: The latter. Just include Jigsaw's module-info.class along with the 
manifest.

Alex

[1] Possible locations are discussed exhaustively from javac's point of 
view at http://openjdk.java.net/projects/jigsaw/doc/ModulesAndJavac.pdf. 
I expect ecj would have its own issues.