[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

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