Implied readability + layers

[Peter Levart]

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. The following situation:

module foo {
     requires public bar;
     ...
}

module baz {
     requires foo;
     ...
}

Should behave exactly like the following:

module foo {
     requires bar;
     ...
}

module baz {
     requires foo;
     requires bar;
     ...
}


...in all possible configurations of layers and classloaders.

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.

Regards, Peter

> On Thu, Nov 5, 2015 at 7:15 PM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 05/11/2015 15:06, Ali Ebrahimi wrote:
>>
>>> :
>>> If com.foo does not use any com.baz's com.bar depend API or com.bar
>>> depend API added latter or requires public in com.baz added later or
>>> removed latter any com.foo may be not aware that, estimating what version
>>> of com.bar for com.foo module that depend on com.bar at 2 would be quite
>>> puzzling and this would be a good candidate for next edition of java
>>> puzzlers book.
>>>
>> Right, module maintainers will need to consider the compatibility impact
>> of dropping requires public. If the motivation is that they are removing
>> APIs then they are likely breaking users of the API anyway.
>   How about adding requires public to M2 and can you say how many modules
> may fail.
>
> I don't understand this strict rule that all consumers of M2 and consumers
> of consumers of M2 should lock to same version of com.bar.
>