Hi Frank, *I think Alex's interpretation of *implied readability is consistent with current definition of concept and expected behavior. Based on your intention public modifier should mean: com.baz embeds com.bar in itself and exports com.bar packages for com.baz's readers and com.foo does not reads module com.bar. If this is expected behavior (that I don't think so) why we use: 'require public com.bar' instead of 'includes com.bar'?
On Tue, Nov 3, 2015 at 7:37 AM, Frank Yuan <frank.y...@oracle.com> wrote: > > > > > 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. This would arise error as of pre-jigsaw with multiple classloaders and expected. I think completed related to layer. Intention of Layers is to handle such scenarios. > Frank > > -- Best Regards, Ali Ebrahimi
