Discussion: #MutableConfigurations, #LazyConfigurationAndInstantiation, #CyclicDependences, & #DiscardableModules

[mark.reinhold at oracle.com]

2016/11/21 7:01:27 -0800, david.lloyd at redhat.com:
> On 11/18/2016 10:30 AM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> David: Is this approach workable for JBoss Modules as well?  If so then
>> I'd like to close these issues out; if not then I'd like to understand
>> if there are additional, smaller changes that would make this approach
>> acceptable while avoiding the complexity of complete solutions to these
>> issues.
> 
> Partially, but not completely...  In particular I am worried about 
> #CyclicDependences (and honestly I'm not entirely convinced that OSGi 
> works completely correctly without it either, for the same reasons that 
> we would need it; I think maybe Mr. Watson's implementation can skate by 
> on an illusion of circularity but I can't see how it would work for us). 
>   I am concerned that it will not be realistic to prune every circular 
> reference in any potential module graph, even using service loaders; 
> IIRC I had to add circularity support to JBoss Modules almost 
> immediately due to cases that could not be practically supported in any 
> other way, and I don't expect that to have changed now.  This is 
> especially true where compile time dependencies differ from run time 
> dependencies, which I think will be fairly common, due to the basic 
> reality (upon which I have expounded in the past) that the minimum 
> practical de facto dependency contract of a given artifact is defined by 
> its ABI, not by its identity or other content.  Some module circuits are 
> fairly long and it's not obvious how they could be resolved.

If you're using an approach similar to what I suggested for OSGi [1]
then you should be able to implement cycles amongst JBoss modules by
inserting the necessary readability edges after each module is
instantiated in its own layer.  This will be much easier with the new
API proposed for #ReadabilityAddedByLayerCreator [2].

> Also I am having a hard time figuring out how to adapt our dependency 
> API to the #NonHierarchicalLayers proposal.  I'll post a separate reply 
> to that mail though.

(I'll reply to that in a moment.)

> Beyond that, I would need to do more testing to see what blows up, but 
> the other portions seem acceptable and practical.

Okay, good.

- Mark


[1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000410.html
[2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-November/000456.html