Implied readability + layers

Alan Bateman Alan.Bateman at
Thu Nov 5 11:38:19 UTC 2015

On 05/11/2015 09:30, Ali Ebrahimi wrote:
> Hi alan,
> 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 in layer1, and 
> sometimes offering a 'requires public' on in layer2, depending 
> on who is reading com.baz in layer1."
> In this case adding 'requires public' on in layer2 does not 
> mean we should pick at 2 for com,foo?

In this example then com.baz in layer1 doesn't know anything about at 2 or other modules that comes into existence in future "child" 
layers, at least not statically.

com.baz does read at 1 and as it declares "requires public" 
then I assume com.baz's exported API must have at 1 types in its 
method signatories. This will usually be good for other modules in 
layer1 or modules in descendants of layer1 that use the com.baz API.

Creating a new layer2 does not change modules in other layers. This 
means that creating layer2 will not change com.baz (in layer1) to read at 2 (in layer2). It is of course possible for com.baz to opt-in 
and reflectively to read at 2 but great care is required (static 
references in code in com.baz will presumably resolve to types in at 1).

> 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 bugs.
> What if compiled against at 2? adding redundant 
> in does not help and my app will fail.
Assuming at 1 and at 2 export the same packages then it should 
fail when you attempt to create the Configuration for layer2 as 
cannot read both.

In this example then you might consider a new instance of module com.baz 
in layer2. That way, layer2 would have, com.baz and at 2.


More information about the jigsaw-dev mailing list