[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

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.

> 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