Implied readability + layers

[Peter Levart]

On 11/05/2015 10:21 PM, Alex Buckley wrote:
> On 11/5/2015 12:42 PM, Ali Ebrahimi wrote:
>> On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart <peter.levart at gmail.com>
>> wrote:
>>> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
>>> So with current implementation of Implied readability w.r.t. layers and
>>> unexpected consequences of its remove or addition, I strongly 
>>> propose to
>>> drop it from current design.
>>>
>>> Unless the rule is very simple. The implied readability should be no
>>> different than explicit readability.
>>>
>>> ...in all possible configurations of layers and classloaders.
>>>
>>
>> Exactly. I agree.
>> Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2.
>>
>> situation1:
>>
>> module foo {
>>      requires public bar;
>>      ...
>> }
>>
>> module baz {
>>      requires foo;
>>      ...
>> }
>>
>> The readability graph for configuration1/layer1 is:
>>    bar at 1 reads java.base
>>    foo reads java.base
>>    foo reads bar at 1
>>
>> The readability graph for configuration2/layer2 is:
>>   bar at 2 reads java.base
>>   baz reads foo
>>   baz reads bar at 1==================
>>
>> But situation2:
>> module foo {
>>      requires bar;
>>      ...
>> }
>>
>> module baz {
>>      requires foo;
>>      requires bar;
>>      ...
>> }
>>
>> The readability graph for configuration1/layer1 is:
>>    bar at 1 reads java.base
>>    foo reads java.base
>>    foo reads bar at 1
>>
>> The readability graph for configuration2/layer2 is:
>>   bar at 2 reads java.base
>>   baz reads foo
>>   baz reads bar at 2==================
>>
>>> If implied readability is taken "symbolically", the same caveats 
>>> apply to
>>> one or the other form - they are just different forms of expressing the
>>> same thing.
>>>
>> As you can see this is currently is not case.
>
> It is the case for modules in the same layer. For modules in different 
> layers, the fundamental design of class loading (initiating loader v. 
> defining loader) means that explicit readability within a layer 
> "dominates" implicit readability across layers. 

You mean explicit readability within a layer must dominate implicit 
readability across layers unless we want the possibility of strange 
ClassCastExceptions like "com.bar.Type can not be cast to com.bar.Type"  
and similar?

So what is written in javadoc for:

     public static Configuration resolve(ModuleFinder beforeFinder,
                                         Layer parent,
                                         ModuleFinder afterFinder,
                                         Collection<String> roots)

      * <p> Each root module is located using the given {@code beforeFinder}
      * and if not found, using the given {@code afterFinder}. Their 
transitive
      * dependences are located using the given {@code beforeFinder}, or 
if not
      * found then the parent {@code Layer}, or if not found then the given
      * {@code afterFinder}. Dependences located in the parent {@code Layer}
      * are resolved no further. </p>

...is true only for explicit dependencies? If "transitive" dependency is 
implicit, then the order is: parent Layer, beforeFinder, afterFinder ?

Or is it just so that the module definition is searched in the specified 
order, but classes are always loaded according to ClassLoader hierarchy 
and their delegation strategy, regardless of Layer configurations that 
just sit above them and must be aligned with them?

So we can achieve the desired effect if we construct our own 
ClassLoader(s) that delegate according to 
beforeFinder/parentLayer/afterFinder ?

Regards, Peter

> A redesign of class loading is not on the table, so anyone creating 
> layers has to carefully track the cross-layer dependencies, just like 
> they have to carefully manage the module->loader mapping.
>
> Alex