Proxy classes and reflection (IllegalAccessException)

[Dawid Weiss]

This is just to let you know that I have deployed our tests on JDK
1.9. Some of them had to be silenced (ignored) waiting for fixes
inside RestEasy, but overall the build is passing after forced
upgrades to Groovy and some JVM switch tweaks.

Thanks everyone for help. While I still think some of the changes in
jigsaw will be painful in practice, I also clearly see the benefits of
the new module system. The aesthetics of splitting rt.jar into more
manageable pieces is an additional pleasant aspect as well. :)

Dawid


On Fri, Apr 8, 2016 at 6:25 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>
>> On Apr 8, 2016, at 4:58 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>>
>> 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
>>
>
> I see Alan has explained this and the issue is now understood.
>
> One thing to add is that a proxy class is only generated in dynamic module if one of the proxy interface is in a named module and not exported.  If you see a proxy class generated in a dynamic module and you run your applications as it is today, it would likely invoke creating a proxy class with some interface in JDK modules, like java.annotations.common module in this case.
>
> If all proxy interfaces are either in unnamed module, or exported from named modules, the proxy class will be generated in unnamed module and existing code should work as it is today.
>
>> 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).
>>
>
> A related note to caching of proxy classes:  The performance of Proxy::newProxyInstance has been improved in JDK 8 and Peter has a patch that brings jdk9 proxy performance even better than JDK 8 [1].
>
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040015.html
>