Implied readability + layers

[Alex Buckley]

On 11/5/2015 2:28 PM, Peter Levart wrote:
> On 11/05/2015 10:21 PM, Alex Buckley wrote:
>>>> 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?

Yes.

> 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 ?

I believe that "transitive" dependencies means "the set of explicit 
dependencies mentioned by 'requires' clauses all the way down to 
java.base". Implicitly read dependencies appear later, and are dominated 
by the explicit dependencies that have already been resolved.

> 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?

It goes without saying that classes are always loaded according to the 
class loaders' delegation strategy (e.g. "a hierarchy") and the JVM's 
loaded class cache (where the "initiating loader" info I mentioned 
earlier is stored). Layers don't change that, so they need to align with 
loader delegation rather than the other way around.

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

I'm not really sure what the desired effect is at this point, but yes 
the loaders passed to a layer should delegate in accordance with the 
resolved graph, and yes the graph would have been resolved on the basis 
of beforeFinder-then-parentLayer-then-afterFinder.

Alex