On 11/2/2015 3:32 PM, Ali Ebrahimi wrote:
On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman <alan.bate...@oracle.com>
wrote:
On 02/11/2015 20:02, Ali Ebrahimi wrote:
Thanks, I see the issue. The reason it didn't duplicate for me is because
I hadn't dropped the requires com.bar.
So the bug is implied readability across layers when the same named module
exists in multiple layers. In this case com.foo should read com.bar@1.
The com.bar (@2) is the same configuration as com.foo is confusing the
code. We'll need to fix this.
So, you say com.foo can not read com.bar(@2) and why?
Based on implied readability module com.foo implicitly reads com.bar, in
other word have requires com.bar;
and because com.bar(@2) is co-layer with com.foo, so
module com.foo should reads com.bar(@2).
com.bar(@2) override com.bar(@1) for com.foo.
How this specified in spec?
It's currently underspecified in Configuration::resolve as "A
readability graph is then constructed to take account of implicitly
declared dependences (requires public)."
We'll have to think about the implication of com.baz in layer1 sometimes
offering a 'requires public' on com.bar in layer1, and sometimes
offering a 'requires public' on com.bar in layer2, depending on who is
reading com.baz in layer1.
Alex
