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

mark.reinhold at oracle.com mark.reinhold at oracle.com
Mon Dec 5 23:07:56 UTC 2016

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

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

More information about the jpms-spec-experts mailing list