> -----Original Message-----
> From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf Of 
> Alex Buckley
> Sent: Tuesday, November 03, 2015 10:27 AM
> To: jigsaw-dev <jigsaw-dev@openjdk.java.net>
> Subject: Re: Question on Implied readability
> 
> 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.

Hi Alex

I don't think so. com.baz declares "requires public com.bar", so com.baz decide 
which com.bar is readable, in this case, decide which com.bar is used by com.foo
Consider the following scenario, which is the common usage of implied 
readability
com.baz provides the following service:
public Object1 getObject();
Object1 is a class defined in com.bar, please not com.bar@2 is not visible to 
com.baz(indeed to avoid conflict, only one com.bar can be visible/readable to 
com.baz), so com.baz construct an Object1 of com.bar@1 during getObject() is 
invoked, and then com.foo get this Object1 instance, now com.foo can only use 
type Object1 of com.bar@1 to interpret it, who guarantee what Object1 of 
com.bar@2 is?! So here the type must be definite, M2 requires public M1,  M3 
requires M2, then which M1 is read by M2, which M1 must be readable to M3. It's 
not related to Layer actually.

Frank


> 
> Alex

Reply via email to