Implied readability + layers

Alex Buckley alex.buckley at
Thu Nov 5 21:39:24 UTC 2015

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>
> wrote:
>> On 05/11/2015 15:06, Ali Ebrahimi wrote:
>>> :
>>> If does not use any com.baz's depend API or
>>> depend API added latter or requires public in com.baz added later or
>>> removed latter any may be not aware that, estimating what version
>>> of for module that depend on 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

A single version of in a program is strongly presumed to be 
better than multiple versions of 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 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.


More information about the jigsaw-dev mailing list