> On Apr 8, 2016, at 4:58 AM, Dawid Weiss <dawid.we...@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@523884b2 > java.annotations.common/javax.ws.rs.ext.Providers module-private > loader jdk.internal.loader.ClassLoaders$PlatformClassLoader@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
