Implied readability + layers

Alan Bateman Alan.Bateman at
Thu Nov 5 08:50:34 UTC 2015

On 04/11/2015 22:45, Ali Ebrahimi wrote:
> :
> So you say at 2 does not override at 1 in layer2 and types 
> will be loaded from at 1 in layer2 for
The configuration for layer2 doesn't contain any modules that require

If you expand the scenario to com.bax requires and if com.bax is 
in configuration2 then you would have com.bax reads at 2 in the 
readability graph (and layer2).

> This is changed from yesterday?
> I now get
> bar1
> bar1
> instead of
> bar1
> bar2
> 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);
>      assertFalse(m1.canRead(m2_v2));
>      assertFalse(m2_v1.canRead(m2_v2));
>      assertFalse(m2_v2.canRead(m2_v1));
>      assertFalse(m3.canRead(m2_v2));
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 mailing list