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