Proxy classes and reflection (IllegalAccessException)

[Dawid Weiss]

Thank you for the magic switch, Mandy! Here's the full output,
including stack traces:

http://pastebin.com/uUb3aLwq

The one referencing the problematic class is:

PROXY: jdk.proxy2/com.sun.proxy.jdk.proxy2.$Proxy65 defined by
jdk.internal.loader.ClassLoaders$PlatformClassLoader at 523884b2
   java.annotations.common/javax.ws.rs.ext.Providers module-private
loader jdk.internal.loader.ClassLoaders$PlatformClassLoader at 523884b2

RestEasy creates this proxy class in
InjectorFactoryImpl.createContextProxy, but its only reason to exist
is (presumably) to keep a cache of proxy classes for the same set of
interfaces (it later calls ContextParameterInjector with a cached
proxy class). This doesn't look correct to me as newProxyInstance
reuses proxy classes internally (although the javadoc here could be
improved).

I modified this locally and removed the proxy cache. On subsequent run
everything worked until I hit another problem, this time somewhere
inside Groovy (reflective scan of all fields, very likely).

java.lang.reflect.InaccessibleObjectException: Unable to make member
of class sun.net.spi.DefaultProxySelector accessible: module java.base
does not export sun.net.spi to unnamed module @124c278f
at sun.reflect.Reflection.throwInaccessibleObjectException(java.base at 9-ea/Reflection.java:420)
at java.lang.reflect.AccessibleObject.checkCanSetAccessible(java.base at 9-ea/AccessibleObject.java:174)
at java.lang.reflect.Constructor.checkCanSetAccessible(java.base at 9-ea/Constructor.java:183)
at java.lang.reflect.Constructor.setAccessible(java.base at 9-ea/Constructor.java:176)
at org.codehaus.groovy.reflection.CachedConstructor$1.run(CachedConstructor.java:41)
at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method)
at org.codehaus.groovy.reflection.CachedConstructor.<init>(CachedConstructor.java:39)
at org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:74)
at org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:64)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
at org.codehaus.groovy.reflection.CachedClass.getConstructors(CachedClass.java:258)
at groovy.lang.MetaClassImpl.<init>(MetaClassImpl.java:213)
at groovy.lang.MetaClassImpl.<init>(MetaClassImpl.java:223)
at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createNormalMetaClass(MetaClassRegistry.java:168)
at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:158)
at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:141)
...

This is going to be an uphill battle with so many dependencies in the stack...

Dawid


On Thu, Apr 7, 2016 at 10:47 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 07/04/2016 21:22, David M. Lloyd wrote:
>>
>> Having the proxy class be public in most circumstances is a
>> 15-plus-year-old contract.
>
> Proxy classes were specified to be public up to Java SE 7. There was a
> significant update in Java SE 8 to specify that the proxy classes be
> non-public when any of the interfaces is not public. The draft changes in
> JDK 9 is further evolution to specify the proxy class accessibility based on
> the least accessible interface.
>
>
>> :
>>
>> The first problem is that a magic dynamic module is created for proxy
>> classes.  This is a bit of a punt because of the natural dissonance/chaos
>> that arises from decoupling the module from the class loader; however
>> there's possibly a better way to mitigate this: let the layer decide how to
>> place the proxy class into a *real* module the same way that in the past,
>> the proxy class was placed into the real class loader as a normal (usually
>> public) class.
>
> There are cases where the proxy class will be generated in the same
> package/module as the proxy interface. Hopefully the "Package and Module
> Membership of Proxy Class" section in the javadoc is clear on all the cases.
>
>>
>>
>> The second problem is that the requirement for adding read edges all over
>> the place for reflection is unreasonable (and has already been recognized as
>> such by the EG).
>
> This is #ReflectionWithoutReadability on the issues list and has already
> been resolved [1].
>
> -Alan
>
> [1]
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-March/000248.html
>
>