[jsr294-modularity-eg] Simple Module System Proposal

[BJ Hargrave]

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

There will be a low-level class loading model. The question is what is the 
model. It is either one class loader for all SMS modules. This is the 
class loading model assumption made today by javac (and probably every 
other java compiler) with respect to package access decisions. Or it is 
more than one class loader. The SMS proposal suggests one class loader per 
module. This allow tree topographies not just a linear topography of 
modules. A can depend upon B and C. B can depend upon D1 and C can depend 
upon D2. D1 and D2 being different versions of D. Assuming the types of D 
do not escape from B or C, the topography can be used. But with a single 
class loader it is impossible. It also means that B and C are exposed to 
each others types which can result in type name conflicts.

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

No one needs to use modularity if they don't wish to. Keep doing what you 
are already doing.

But even using module accessibility requires source code changes which 
will require thought (probably significant) on the part of the developer 
to determine the proper module boundaries. This is the same thought 
process which will include understanding class loader boundaries. There is 
no free lunch on establishing these encapsulation boundaries. Using them 
will likely require code restructuring and changes.

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

I guess I am confused by your term "modularize for the deployment 
benefits". Is this just organizing code into jars to simplify 
download/install? Or does it include actually modularizing the code as in 
using module accessibility or other levels of encapsulation? The former is 
not really modularity (at least not in any formal sense). Modularizing 
existing code is non-trivial regardless of whether one uses the module 
access modifier or class loader based visibility restrictions.

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

This seems to be the holy grail that everyone wants: easy modularity. 
People wants the benefits of the encapsulation provided by modularity, but 
they don't want to make change to their code. I guess I don't see the easy 
on-ramp to modularity that you claim for module access+single class loader 
over module access+multiple class loaders. Non-trival code restructuring 
is still needed. One must define the module boundaries and organize their 
code with respect to those boundaries.

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

I am not sure how you read that from my comment. I do not imply or mean 
that. 

-- 

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-observer/attachments/20090914/c12e750b/attachment.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg