[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

BJ Hargrave wrote:
>  > Thanks Peter. In a nutshell, you're saying the simple module system is
>  > the Reference Implementation of JSR 294.
> 
> I think it is more correct to say JSR 294 specifies the Simple Module 
> System. The RI for JSR 294 could just implement the Simple Module 
> System. 

True.

> The RI could also be Jigsaw(runtime) and javac(compile-time).

True.

> Jigsaw will have many more features beyond those specified in the Simple 
> Module System. But any modules developed to conform to the Simple Module 
> System specification can be deployed on Jigsaw as well as other module 
> systems which will provide support for the Simple Module System 
> specification.

True.

>  > This raises the question: who determines what is "in" a visible module?
>  > I expect javac could use Jigsaw metadata, if present, to determine the
>  > answer.
> 
> I would assume that javac would use the Simple Module System metadata to 
> make this determination since javac would be the reference 
> implementation of the compiler portion of the Simple Module System in 
> the JSR 294 spec.
...
> javac providing support for Jigsaw modules is beyond the specification 
> of the Simple Module System.

These two statements could be taken to mean that javac uses metadata 
from the Simple Module System and from no other module system.

Today, javac supports numerous mechanisms for configuring visibility 
that are outside any Java platform specification. classpath, sourcepath, 
and ct.sym come to mind, plus the new modulepath mechanism.

I often hear that ecj (or at least some core jdt subset) can configure 
visibility with an OSGi manifest.

It would be most irregular if javac used only Simple Module System 
metadata and ignored any Jigsaw metadata present.

A vendor who implements a JSR's specification is not prevented from 
offering additional functionality for customers who choose to use it.

>  > At runtime, it is attractive to initially rely on a simple class loading
>  > model and then refine it with Jigsaw/OSGi-specific metadata as your
>  > application grows. But why one class loader per module in the simple
>  > module system? It will cause great headaches for legacy code. One class
>  > loader per application would be far more familiar. Don't underestimate
>  > the learning curve already coming from dependencies and versioning.
> 
> One class loader per module is the easiest mapping. It is a mapping that 
> is already supported by Jigsaw and OSGi. Other M:N mappings (where 
> either M or N can be 1) require some metadata to be defined to establish 
> the mapping. This metadata will be brittle and quickly become out of 
> date if it is maintained in the modules. If it is kept outside of the 
> modules, then it is another artifact to be defined and managed.

With respect, what is the evidence that one class loader per module is 
the easiest mapping?

And easiest for who? A majority of Java developers are not familiar with 
the implications of multiple class loaders. Surely we can agree on that.

Any default mapping will require extra-systemic metadata in OSGi and 
Jigsaw at some point, since each supports a mapping that the other does 
not. The aim should be a widely-understood and compatible default; or to 
stick to module membership at compile-time and runtime (as the heading 
in the proposal indicated) and not prescribe a class loading model at all.

Alex