Implied readability + layers
ali.ebrahimi1781 at gmail.com
Thu Nov 5 09:30:33 UTC 2015
So far quite disappointing!
But I think Alex's last response on this topic says opposite of this:
"We'll have to think about the implication of com.baz in layer1 sometimes
offering a 'requires public' on com.bar in layer1, and sometimes offering a
'requires public' on com.bar in layer2, depending on who is reading com.baz
In this case adding 'requires public' on com.bar in layer2 does not mean
we should pick com.bar at 2 for com,foo?
This scenario would have many usages in future when world would filled with
modules and developers would have to use newer versions of modules to fix
What if com.foo compiled against com.bar at 2? adding redundant requires com.bar
in com.foo does not help and my app will fail.
So what is advantage of multiple layers?
On Thu, Nov 5, 2015 at 12:20 PM, Alan Bateman <Alan.Bateman at oracle.com>
> 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