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. Up to the point, yes, this is my view even though I don't mean com.baz embeds com.bar physically. But if com.foo intends to read com.bar, it should declare "requires com.bar" explicitly. Article http://openjdk.java.net/projects/jigsaw/spec/sotms/ states the purpose of implied readability as well as the common use case. The key of this design is at that the module, which provides some service, take the responsibility to make some other necessary modules readable to the consumer module. Or it can encapsulate the interface in the necessary modules, that it won't declare "requires" with "public". If the consumer module doesn't demand the producer module, consumer also won't need to read those "necessary modules". Besides the conceptual aspect, it doesn't work if consumer uses any instance returned from producer but consumer interprets it to be the type in any different module with which the producer reads, as the example I gave in my pervious mail. 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 <mailto: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 <mailto:com.bar@2> is note 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 <mailto: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 <mailto:com.bar@1> to interpret it, who guarantee what Object1 of com.bar@2 <mailto: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. Our gap may be you think com.baz should construct Object1 with the type in com.bar@2 <mailto:com.bar@2> , but in your code, com.baz does read com.bar@1 <mailto:com.bar@1> according to its static module descriptors and your layer's configuration, and then in com.baz, the hard code will construct Object1 with the type in com.bar@1 <mailto:com.bar@1> , you can use reflection to addReads(com.bar@2 <mailto:com.bar@2> ) inside com.baz but I guess it should fail because of duplicate module name, further, package name and qualified class name should not be duplicate in same one scope. I said it's not related to Layer because I wanted to emphasize it's related to Layer properties. Anyway we don't need to struggle on the words. Frank -- Best Regards, Ali Ebrahimi
