[jsr294-modularity-eg] Simple Module System Proposal
Alex.Buckley at Sun.COM
Mon Sep 14 21:59:43 EDT 2009
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.
> 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
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
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
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
> 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
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.
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer