Implied readability + layers

[Alex Buckley]

On 11/5/2015 10:39 AM, 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.
>
> 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.

A single version of com.bar in a program is strongly presumed to be 
better than multiple versions of com.bar in a program.

I showed elsewhere that explicit readability within a parent layer 
causes class loading to behave in such a way that modules in a child 
layer cannot override modules in the parent layer. That's just how the 
JVM works. Sometimes that will rear its head as "consumers of M2 are 
locked to the same com.bar as consumers of consumers of M2", sometimes 
it won't, depending on which layers have which modules. But unlimited 
support for multiple versions in all possible layer arrangements is not 
a goal.

Alex