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

[David M. Lloyd]

On 11/21/2016 03:52 PM, mark.reinhold at oracle.com wrote:
> 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].

I asked earlier whether this allows the class resolver to resolve 
against modules with a lately-added readability edge as you describe 
here, and it sounded like the answer was "no"; did I miss something?  If 
my understanding was right, then this doesn't allow for circularity at 
the class level where we need it.

>> 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
>

-- 
- DML