[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

BJ Hargrave wrote:
>> 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.

Of course B and C may have dependencies which resolve to a single 
version of D. Where different versions of D are truly requested, we are
not talking about a simple scenario. Assumptions or checks must be made 
to keep a consistent class space for A. Now we're talking about 
controlling re-export and search order, or a declaration by A's 
programmer that types propagating up through B are not leaked to C.

I recognize the single loader model is inadequate for the complex 
dynamic environments found in app servers. But the SMS proposal makes no 
reference to supporting app servers. It focuses on simple, simple, 
simple. I cannot imagine anyone arguing that the implications of 
multiple loaders are simple. The implications of a single loader are 
simple, but of course restrictive - and for a feature embedded into the 
Java language, I'll take that trade-off.

To bring forward a related issue, I don't see how the SMS proposal - 
assuming multiple loaders, I suppose - can claim compile-time fidelity 
unless compilers are mandated to track types w.r.t. their defining 
module (type T *from D1* versus *from D2*). Yet you said you weren't 
meaning to mandate this.

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

Yes.

> This is the same thought process which will include understanding
> class loader boundaries.

No! Today an app is a bunch of jar files with implicit dependencies on 
other jars somewhere on the classpath. It will be a huge net benefit for 
the Java community if jars are thought of as logical modules with 
versioned identities and versioned dependencies. Not a single access 
control modifier needs to change to get there.

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

As above, it's more than jars; it's about logical modules with 
common-case first-class dependency and version information.

> Or does it include actually modularizing the code as in using module
> accessibility or other levels of encapsulation?

Strengthening encapsulation via module-private accessibility is a later 
and more advanced step.

> The former is not really modularity (at least not in any formal
> sense).

What formal definition of modularity do you have in mind?

> Modularizing existing code is non-trivial regardless of whether one
> uses the module access modifier or class loader based visibility
> restrictions.

Naturally any structural change to existing code is non-trivial. The 
most pragmatic way for developers to get started is by documenting 
visibility requirements currently expressed through the classpath. By 
definition, developers coming from the classpath cannot usefully be 
requiring multiple versions of a given module.

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

The on-ramp to modularity is as I've described it above. It involves 
reifying the classpath into module-info.java and learning about how to 
model evolution with versions and version policies. Dealing with 
optional dependencies too. Refactoring a large, first-pass module into 
smaller modules without consumers' knowledge.

Hiding internals with module-private accessibility need not be the first 
task. If module M depends on module N and has visibility to slightly too 
many of N's public types, that can be fixed later.

For the users I have in mind, multiple loaders and dynamism are edge 
cases, configurable through module-system-specific annotations.

Alex
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg