Implied readability + layers

[Ali Ebrahimi]

Hi,

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

> 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
> com.bar 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 com.bar 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:
  com.bar at 1 reads java.base
  com.baz reads com.bar at 1
The readability graph for configuration2 is:
  com.bar at 2 requires java.base
  com.foo reads java.base
  com.foo reads com.baz
  com.foo reads com.bar at 2


> com.baz does read com.bar at 1 and as it declares "requires public com.bar"
> then I assume com.baz's exported API must have com.bar 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 com.foo does not contain any type of com.bar you
wouldn't have any issue, otherwise com.foo 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 com.bar at 2
> (in layer2). It is of course possible for com.baz to opt-in and
> reflectively to read com.bar at 2 but great care is required (static
> references in code in com.baz will presumably resolve to types in com.bar 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 com.foo compiled against com.bar at 2? adding redundant requires com.bar
> in com.foo does not help and my app will fail.
>
> Assuming com.bar at 1 and com.bar at 2 export the same packages then it should
> fail when you attempt to create the Configuration for layer2 as com.foo
> cannot read both.
>

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


> In this example then you might consider a new instance of module com.baz
> in layer2. That way, layer2 would have com.foo, com.baz and com.bar 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 com.bar at 1 for layer1 and layer2
2) pick com.bar at 1 for layer1 and com.bar at 1 for layer2
3) pick com.bar at 2 for layer1 and layer2

I think 2 would be best and flexible choice.


Best Regards,
Ali Ebrahimi