Question on Implied readability

Frank Yuan frank.yuan at
Tue Nov 3 10:00:50 UTC 2015


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 in itself and exports packages for com.baz's readers and does not reads module


Up to the point, yes, this is my view even though I don't mean com.baz embeds physically. But if intends to read, it should declare "requires" explicitly. Article 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' instead of 'includes'?



On Tue, Nov 3, 2015 at 7:37 AM, Frank Yuan <frank.yuan at <mailto:frank.yuan at> > wrote:


Hi Alex

I don't think so. com.baz declares "requires public", so com.baz decide which is readable, in this case, decide which is used by
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, please not at 2 < at 2>  is note visible to com.baz(indeed to avoid conflict, only one can be visible/readable to com.baz), so com.baz construct an Object1 of at 1 < at 1>  during getObject() is invoked, and then get this Object1 instance, now can only use type Object1 of at 1 < at 1>  to interpret it, who guarantee what Object1 of at 2 < at 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 at 2 < at 2> , but in your code, com.baz does read at 1 < at 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 at 1 < at 1> , you can use reflection to addReads( at 2 < at 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.





Best Regards,

Ali Ebrahimi

More information about the jigsaw-dev mailing list