Implied readability + layers
Alan.Bateman at oracle.com
Thu Nov 5 08:50:34 UTC 2015
On 04/11/2015 22:45, Ali Ebrahimi wrote:
> So you say com.bar at 2 does not override com.bar at 1 in layer2 and types
> will be loaded from com.bar at 1 in layer2 for com.foo?
The configuration for layer2 doesn't contain any modules that require
If you expand the scenario to com.bax requires com.bar and if com.bax is
in configuration2 then you would have com.bax reads com.bar at 2 in the
readability graph (and layer2).
> This is changed from yesterday?
> I now get
> instead of
> for my yesterday sample code. quite supersizing!
It will take time to shake out issues and it's great that you are trying
things and finding issues. At this time the only issue I'm aware of is
where there are equal ModuleDescriptors in multiple layers. That one
requires an API change as I mentioned, we'll get that sorted out soon.
> Second, what can you say for this test case:
> Module m1 = layer1.findModule("m1").get();
> Module m2_v1 = layer1.findModule("m2").get();
> Module m2_v2 = layer2.findModule("m2").get();
> Module m3 = layer2.findModule("m3").get();
> assertTrue(m2_v2.getLayer() == layer2);
In this example then m3 is the only module in layer2 and so
layer2.findModule("m2") will find m2 in its parent (hence m2_v2 == m2_v1).
If you adjust the example so that m3 requires m2 then layer2 will
contain m3 and m2 at 2.
It's also possible for m3 require both m1 and m2. The result may be a
surprising as m3 will read m2 at 1 and m2 at 2. Clearly if both versions of m2
were to export the same package then it would fail but there are no
exports in this test case.
More information about the jigsaw-dev