Implied readability + layers

Ali Ebrahimi ali.ebrahimi1781 at
Thu Nov 5 13:17:19 UTC 2015


On Thu, Nov 5, 2015 at 3:08 PM, Alan Bateman <Alan.Bateman at>

> On 05/11/2015 09:30, Ali Ebrahimi wrote:
> Hi alan,
> So far quite disappointing!
> 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.

I know that and may be even com.baz not compatible with at 2. So I
don't expect sublayers's modules propagated in parent layers.
However, in current design we don't involve module version in declaration
of dependence and I think that is good decision.
So my assumption is:

The readability graph for configuration1 is: at 1 reads java.base
  com.baz reads at 1
The readability graph for configuration2 is: at 2 requires java.base reads java.base reads com.baz reads at 2

> 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.
This does not affect modules belong layerx < layer2 so can be happy.
If API usage of com.baz in does not contain any type of you
wouldn't have any issue, otherwise must live on layer1.

> 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
> ).
See above.

> 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 requires
> 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.

I think this is reasonable that when executing bytecode belong to layer2
( or com.poo) that request for types of module we pick from at 2.

> 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.

If I'm not owner of com.baz or what do for com.baz dependent modules

I think we have tree possible choices:
1) pick at 1 for layer1 and layer2
2) pick at 1 for layer1 and at 1 for layer2
3) pick at 2 for layer1 and layer2

I think 2 would be best and flexible choice.

Best Regards,
Ali Ebrahimi

More information about the jigsaw-dev mailing list