[jsr294-modularity-eg] Simple Module System Proposal

[BJ Hargrave]

> > 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.

All the second statement means is that the spec, which does not currently 
describe -classpath, should also not describe Jigsaw (or OSGi) specific 
options or details. If a java compiler, such as javac or ecj, wishes to 
add support for other modules systems, it can.

The statements are about what must be in the spec and what must not be in 
the spec. Not what an implementation can do.

So we are not in disagreement here.

> > 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?

>From a convention over configuration point of view, it is very clear and 
easy to specify that one artifact is one module and has one class loader. 
Any other mapping requires some amount of configuration and I would say is 
therefore more complicated. 

> 
> 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.

Sure. And we can also agree that a majority of Java developer are not 
familiar with the implications of modularity (this is the main struggle 
most people have using OSGi). As you have said before, there is no legacy 
here. This is new and we must communicate with Java developers about how 
to use it. Having a convention based mapping between artifacts, modules 
and class loaders seems the most simple mapping to explain.

> 
> 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.

SMS seeks to concretely define the boundaries such that module access 
checks and package access checks at compile-time match those at runtime 
(fidelity). Having a well specified boundary for modules enables module 
access check fidelity. The same is necessary for package access check 
fidelity. To date, the assumption of java compilers is that all visible 
types are loaded by the same class loader so that all package access 
checks pass if the caller and the receiver have the same package name. Not 
specifying a class loading model for SMS is the same as specifying that 
all SMS modules share the same class loader since the compiler will have 
no information to base package access decisions upon (other than package 
names of the types). In order to provide runtime fidelity with the 
compiler, all SMS modules must then be loaded into the same class loader 
which seems a heavy restriction[1]. Or else we state that fidelity only 
applies to module access checks and not package access checks which seems 
sad when we have done so much for module access fidelity.

[1] For a dynamic module system like OSGi, this restriction also means 
that SMS modules can never be unloaded without unloading all SMS modules 
:-( So it is a significant disabler for OSGi.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave at us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090910/76d3fd22/attachment.html>