[jsr294-modularity-eg] Simple Module System Proposal

[Peter Kriens]

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