On 12/09/2015 09:43 AM, Stephane Epardaud wrote:

On 08/12/15 23:32, Mandy Chung wrote:
Good point. Existing code should use Annotation.annotationType()
instead of Annotation.getClass(). Annotation is an interface. Calling
annotation.getClass() will only return the implementation class that
may be encapsulated and not exported to the caller. This is not
specific to proxies. If the annotation were implemented with some
concrete implementation class that is not-exported to caller to use,
annotation.getClass().getMethod(…).invoke(…) will get IAE in that case.
I did, which got me out of the jdk.proxy1 module issue, but then I was
left with having to add a read to that annotation's module, which is
only slightly better.


I think it will become common to dynamically .addRead() edges to modules that are only discovered at runtime. But that means that existing code will have to be changed and that changed code will not run on JDK8- unless a layer above Module API is coded in each application that dispatches to .addRead(targetModule) for the target Class if running on JDK9+, but does nothing for JDK8-. If .addRead() is always invoked before reflective accesses to target class, it will defeate the purpose of (non)readability - the "soft" part of encapsulation. It is really important to respect the readability only in compile-time, so that you don't use the types from a module that you don't declare to depend on, and perhaps at run-time for code that statically refers to types. Reflection is mostly about types that you discover only at runtime. So would it be so wrong to bend a little the accessibility rules for reflective access and not count readability of target module in their evaluation? This would make the code more portable to earlier platforms while not breaking the "hard" part of encapsulation - the exportability of packages.

Regards, Peter

Reply via email to