[jsr294-modularity-eg] Simple Module System Proposal

[Richard S. Hall]

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

-> richard

>
>> 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?
>
> Alex
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg