[jsr294-modularity-eg] Simple Module System Proposal
hargrave at us.ibm.com
Thu Sep 10 17:25:29 EDT 2009
> > I would assume that javac would use the Simple Module System metadata
> > 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
> > 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
> > 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
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. 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.
 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.
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...
More information about the jsr294-modularity-eg