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

[David M. Lloyd]

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.

>>                                                        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?
>
> No, I don't think so.  Readability edges added at run time only affect
> run-time access-control checks; they don't affect later module-resolution
> operations.
>
>>                                                                       If
>> my understanding was right, then this doesn't allow for circularity at
>> the class level where we need it.
>
> The JPMS resolver does not allow cycles amongst modules; this has long
> been the case.  (Circularity amongst classes is allowed, as it must be.)

Right, and therefore we have come full circle to #CyclicDependences.

> 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.  It's not sufficient.  The issue document says "easier", and 
talks about philosophical points, but here in the mud the reality is 
that it's just easier to allow cycles (in fact we made this change over 
5 years ago).  Debugging an unexpected run time cycle is a major pain, 
whereas allowing cycles cost us nothing and instantly alleviated a 
number of practical difficulties (everything *just works*).  The grim 
reality is that a module dependencies simply do not always form DAGs at 
run time in the real world, especially once you have hundreds or 
thousands of interconnected modules, any more than classes do - and it's 
an unreasonable restriction to try to force it, for many of the same 
reasons that such a restriction would be unreasonable for classes.

-- 
- DML