Is there really a jdk.proxy1 module?
peter.levart at gmail.com
Wed Dec 9 11:00:09 UTC 2015
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
More information about the jigsaw-dev