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

[mark.reinhold at oracle.com]

2016/11/29 18:47:59 -0800, david.lloyd at redhat.com:
> On 11/29/2016 06:09 PM, mark.reinhold at oracle.com wrote:
>> 2016/11/22 13:19:19 -0800, david.lloyd at redhat.com:
>>> On 11/21/2016 03:52 PM, mark.reinhold at oracle.com wrote:
>>>> ...
>>>> 
>>>> 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
>> 
>> (What's a "class resolver" in this context?)
> 
> The part of the class loader that resolves references between classes 
> and performs linkage.  There seems to be no non-overloaded term for 
> this, anymore.

If that's what you mean by "class resolver" then you're really talking
about class loaders, not the module system, or at least not JPMS, since
JPMS doesn't change how class loading works.

>> ...
>> 
>> If you want to allow cycles amongst your own modules then you can resolve
>> them yourself and add whatever cycle-inducing readability edges you need.
>> That is, as I understand it, how Watson's OSGi embedding works.
> 
> But it fails when the actual classes have direct references to one 
> another.

Can you be more specific?  How does it fail?  Is Watson's OSGi embedding
broken?

In addition to writing your own resolver you can -- and I've assumed that
you, like Watson, would -- write your own class loaders to resolve class
references in whatever way you require, even looking up classes in nearby
cyclically-related modules according to whatever module-graph data
structure you construct.

Unless that approach is broken then my original question remains [3]:

  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.

- 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
[3] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-November/000458.html