[jsr294-modularity-eg] Simple Module System Proposal
Richard S. Hall
heavy at sun.com
Mon Sep 14 12:57:12 EDT 2009
On 9/11/09 16:34, Alex Buckley wrote:
> BJ Hargrave wrote:
>> 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.
> Convention would dictate that modules share a loader because that's
> what happens to JARs on the classpath today. The problems of the
> classpath - that it's a brittle second-class mechanism that allows
> split packages - can be solved by a module system with first-class
> metadata and appropriate rules about consistent class spaces. There is
> no need to fixate on a low-level class loading model.
>> > And easiest for who? A majority of Java developers are not familiar
>> > the implications of multiple class loaders. Surely we can agree on
>> 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.
> Being easy to explain will be no good if the mapping requires material
> rewrites of programs which assume a single loader. Now, I think we
> would agree that such programs are not the 80% common case, so I will
> not dwell on them except to say that we are not starting from a clean
> slate and should consider the entire space of Java programs looking to
> migrate to deployment modules.
> What I will highlight are the majority of programs - which do not
> assume a single loader but nor are especially loader-aware - that will
> face a new variable in multiple loaders. Developers should be able to
> modularize for the deployment benefits without having to suddenly
> worry about a new execution model. You paddle before you can swim.
> As developers gain experience with modularity, the universally
> familiar accessibility model can be employed ('module') to strongly
> partition classes in the same loader from different modules. (At
> compile-time too.) Or they can look to mechanisms in other module
> systems if, say, dynamic loading and unloading are required.
> I think that's a very pragmatic story for this point in Java's life.
For me, the real value of the SMS is the standard/concrete module
definition which can easily be re-used across module systems. By trying
to constrain the SMS solution to be one class loader for all modules you
eliminate the possibility of these modules ever supporting side-by-side
versions or dynamism, which means the re-use story for SMS modules in
OSGi basically goes out the window, since these modules wouldn't fit it.
In GlassFish (and other EE servers, I imagine), we need to be able to
support side-by-side versions and dynamism, so it would be nice to have
SMS modules be amenable so we could possibly leverage them.
>> 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.
> This implies that a Java compiler must tag visible types with their
> containing module name+version for access control enforcement. Do you
> really mean this?
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-eg