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.bate...@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@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
