Implied readability + layers
Ali Ebrahimi
ali.ebrahimi1781 at gmail.com
Thu Nov 5 20:42:43 UTC 2015
Hi,
On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart <peter.levart at gmail.com>
wrote:
>
>
> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
>
> Hi,
> So with current implementation of Implied readability w.r.t. layers and
> unexpected consequences of its remove or addition, I strongly propose to
> drop it from current design.
>
>
> Unless the rule is very simple. The implied readability should be no
> different than explicit readability.
>
> ...in all possible configurations of layers and classloaders.
>
Exactly. I agree.
Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2.
situation1:
module foo {
requires public bar;
...
}
module baz {
requires foo;
...
}
The readability graph for configuration1/layer1 is:
bar at 1 reads java.base
foo reads java.base
foo reads bar at 1
The readability graph for configuration2/layer2 is:
bar at 2 reads java.base
baz reads foo
baz reads bar at 1==================
But situation2:
module foo {
requires bar;
...
}
module baz {
requires foo;
requires bar;
...
}
The readability graph for configuration1/layer1 is:
bar at 1 reads java.base
foo reads java.base
foo reads bar at 1
The readability graph for configuration2/layer2 is:
bar at 2 reads java.base
baz reads foo
baz reads bar at 2==================
> If implied readability is taken "symbolically", the same caveats apply to
> one or the other form - they are just different forms of expressing the
> same thing.
>
As you can see this is currently is not case.
But with one simple rule "Always current layer's version of module win over
parent layer's one" we would have same readability graphs for both
situations.
--
Best Regards,
Ali Ebrahimi
More information about the jigsaw-dev
mailing list