[ https://issues.apache.org/jira/browse/GROOVY-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429445#comment-17429445 ]
Eric Milles edited comment on GROOVY-10302 at 10/15/21, 6:37 PM: ----------------------------------------------------------------- After much investigation I have determined that the compiler is creating MOP method "super$4$findClass(String)" to assist "super.findClass(name)". However at run-time, Java 16 does not see "protected java.net.URLClassLoader#findClass(java.lang.String)" as accessible to CachedClass. And so it expects "super$6$findClass" which is a reference to ClassLoader#findClass. I'm not sure what changed between Java 15 and Java 16 that has unnamed modules unable to access public classes in exported packages. That is, the "is open" check in Java9#checkAccessible behaves differently in pre-16 and 16+. I experimented with opening up access but this led to a lot of problems in swing builder and other components that receive private references and then try to call overridden methods. GROOVY-4922 is one reference in this part of the code (MetaClassImpl#replaceWithMOPCalls) where the MOP name cannot be directly resolved in all cases. Is it reasonable to expect that a public class that is in an exported package should have its non-private methods indexed? Or is some kind of workaround similar to 4922 in order? [~paulk] [~daniel_sun] [~blackdrag] was (Author: emilles): After much investigation I have determined that the compiler is creating MOP method "super$4$findClass(String)" to assist "super.findClass(name)". However at run-time, Java 16 does not see "protected java.net.URLClassLoader#findClass(java.lang.String)" as accessible to CachedClass. And so it extects "super$6$findClass" which is a reference to ClassLoader#findClass. I'm not sure what changed between Java 15 and Java 16 that has unnamed modules unable to access public classes in exported packages. That is, the "is open" check in Java9#checkAccessible behaves differently in pre-16 and 16+. I experimented with opening up access but this led to a lot of problems in swing builder and other components that receive private references and then try to call overridden methods. GROOVY-4922 is one reference in this part of the code (MetaClassImpl#replaceWithMOPCalls) where the MOP name cannot be directly resolved in all cases. Is it reasonable to expect that a public class that is in an exported package should have its non-private methods indexed? Or is some kind of workaround similar to 4922 in order? [~paulk] [~daniel_sun] [~blackdrag] > StackOverflowError on Java 16+ for override method that delegates to super > -------------------------------------------------------------------------- > > Key: GROOVY-10302 > URL: https://issues.apache.org/jira/browse/GROOVY-10302 > Project: Groovy > Issue Type: Bug > Components: jdk conflict > Affects Versions: 4.0.0-beta-1 > Reporter: Eric Milles > Priority: Major > > Consider the following: > {code:groovy} > void test() { > def list = [] > def loader = new GroovyClassLoader() { > @Override > protected Class<?> findClass(String name) throws > ClassNotFoundException { > list.add(name); super.findClass(name) > } > } > Class result = loader.findClass('foo.bar.Baz') > } > {code} > When executed on Java 16+ it produces a StackOverflowError when resolving > "super.findClass(name)". > {code} > java.lang.StackOverflowError > at > org.codehaus.groovy.runtime.memoize.LRUCache.getAndPut(LRUCache.java:63) > at > org.codehaus.groovy.vmplugin.v8.CacheableCallSite.getAndPut(CacheableCallSite.java:48) > at > org.codehaus.groovy.vmplugin.v8.IndyInterface.lambda$fromCache$2(IndyInterface.java:298) > at > org.codehaus.groovy.vmplugin.v8.IndyInterface.doWithCallSite(IndyInterface.java:367) > at > org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:295) > at TestScript0$1.findClass(TestScript0.groovy:8) > at > java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:116) > at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) > at groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1424) > at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1140) > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:146) > at TestScript0$1.findClass(TestScript0.groovy:8) > at > java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:116) > at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) > at groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1424) > at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1140) > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:146) > at TestScript0$1.findClass(TestScript0.groovy:8) > at > java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:116) > at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) > at groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1424) > at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1140) > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:146) > at TestScript0$1.findClass(TestScript0.groovy:8) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)