Is there really a jdk.proxy1 module?

[Peter Levart]

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