[
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)
