[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

Thanks Peter. In a nutshell, you're saying the simple module system is 
the Reference Implementation of JSR 294.

At compile-time, modifications to javac already provide simple module 
system functionality. javac uses a modulepath to determine module 
membership - I think everyone liked that - and performs very simple 
resolution on dependencies in module-info.java to set up the compilation 
environment. There are no class loaders at compile-time so only one 
version of a module is visible to code being compiled. It's not 
analogous to the simple module system proposal at runtime, but it's 
better than classpath because javac can ban split packages in visible 
modules.

This raises the question: who determines what is "in" a visible module? 
I expect javac could use Jigsaw metadata, if present, to determine the 
answer. A Jigsaw local dependency allows a physically split package to 
be logically unsplit; the contents of multiple physical modules become 
the content of one logical module. javac could work at the logical 
level, resolving classes in the same package against different physical 
modules unified through local dependencies. An OSGi-aware compiler could 
do the same for fragment bundles.

Just trying to find the boundary between the simple module system 
(assuming it is indeed 'physical') and other module systems.

At runtime, it is attractive to initially rely on a simple class loading 
model and then refine it with Jigsaw/OSGi-specific metadata as your 
application grows. But why one class loader per module in the simple 
module system? It will cause great headaches for legacy code. One class 
loader per application would be far more familiar. Don't underestimate 
the learning curve already coming from dependencies and versioning.

Alex

Peter Kriens wrote:
> Alex,
> We do think that it is 'physical' ... Though it can be supported by 
> Jigsaw and OSGi, the class loading rules for this simple module system 
> must be concrete so the code in the these simple modules can rely on 
> them. By keeping it a simple module system we expect that it will not be 
> too hard to support it in Jigsaw, OSGi, and maybe even a module system 
> implementation that limits itself to the simple module system design.
> 
> We agree that a proper subset of Jigsaw/OSGi might be difficult to 
> define, however we believe the simple module system would not require 
> too much effort to be supported by existing and future module systems.
> 
> Kind regards,
> 
>     Peter Kriens
> 
> On 1 sep 2009, at 03:37, Alex Buckley wrote:
> 
>> Richard S. Hall wrote:
>>> I think there are two possibilities here:
>>>   1. We simply allow multiple versions and provide a "class path" like
>>>      approach where the versions are merged/shadowed based on the
>>>      search order. In this particular example, the search order would
>>>      be depth first like this: D1->B->D2->C->A. Clearly, this can lead
>>>      to lead to class space consistency errors like with the class
>>>      path, which leads us to the other alternative...
>>>   2. We disallow multiple versions and this scenario would result in
>>>      some sort of resolve exception.
>>> It is not clear which is the best approach, but the safest is 
>>> approach (2). We should discuss this in the expert group to reach 
>>> consensus.
>>
>> Thanks. I agree with an emphasis on safety.
>>
>> Thinking about resolution prompts me to ask if the simple module 
>> system is intended to be 'logical' or 'physical'. It is plausible to 
>> define a 'lowest common denominator' model for dependencies and 
>> versioning, supported by both Jigsaw and OSGi. So far, so logical; the 
>> simple module system is merely a bunch of concepts common to Jigsaw 
>> and OSGi. If a simple module has no Jigsaw or OSGi metadata, it looks 
>> like we have WORA.
>>
>> But do we? The runtime model proposed in the Module Membership section 
>> is neither exactly Jigsaw nor exactly OSGi. Even if it is OSGi-esque 
>> by virtue of one class loader per module, I doubt it will remain so 
>> once the details of search order, re-export, optionality, and class 
>> space consistency are worked out. (Resolution is non-trivial, and 
>> 'Module Membership' hardly does it justice.) Code in a simple module 
>> will rely on these details. So there is really a third module system; 
>> you could physically use it without having Jigsaw or OSGi installed.
>>
>> Unless, that is, you think the simple module system's runtime model 
>> can be simplified so it too is a proper subset of Jigsaw and OSGi. 
>> That in turn requires a common resolution story for Jigsaw and OSGi. 
>> Challenging, since Jigsaw and OSGi occupy different points in the 
>> design space. (Decomposition of tightly-coupled legacy code + static 
>> resolution v. decomposition of loosely-coupled service-oriented code + 
>> dynamic resolution ... I'm sure it's clear which is which :-)
>>
>> Just trying to draw out the hard problems early.
>>
>> Alex
>> _______________________________________________
>> jsr294-modularity-eg mailing list
>> jsr294-modularity-eg at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg