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

David M. Lloyd david.lloyd at redhat.com
Tue Nov 22 21:19:19 UTC 2016

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


More information about the jpms-spec-observers mailing list