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
