[
https://issues.apache.org/jira/browse/GROOVY-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496329#comment-17496329
]
Paul King commented on GROOVY-10503:
------------------------------------
I would certainly like to do a release with the current addition of Java 15
support before we look into this PR further.
With respect to this PR, we know that certain Groovy code might have trouble
running on later JDKs. So, it might be setting a false expectation that the
newer JDKs will work without problems. This isn't related to changes in Groovy
but rather changes in the JDKs turning off certain features that dynamic parts
of Groovy rely on. It might be possible to progress further but would require a
large effort over and above the current proposed changes.
Do you have any problems using Groovy 3 or 4? With Groovy 3, you could even
revert to the old parser and avoid using --indy to have a 2.5.x like
experience.
> Embed ASM 9.2 in Groovy 2.5.x
> -----------------------------
>
> Key: GROOVY-10503
> URL: https://issues.apache.org/jira/browse/GROOVY-10503
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
> Affects Versions: 2.5.15
> Reporter: Alexander Kriegisch
> Priority: Major
> Fix For: 2.5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> When compiling Groovy scripts in a Groovy project running under JDK 16+,
> there are error messages like:
> {code:groovy}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> General error during class generation: Unsupported class file major version 61
> java.lang.IllegalArgumentException: Unsupported class file major version 61
> at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:196)
> at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:177)
> at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:163)
> at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:284)
> at
> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81)
> at
> org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:251)
> at
> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:189)
> at
> org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:169)
> at
> org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:125)
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClassNullable(AsmReferenceResolver.java:57)
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:44)
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveNonArrayType(AsmReferenceResolver.java:79)
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveType(AsmReferenceResolver.java:70)
> at
> org.codehaus.groovy.ast.decompiled.MemberSignatureParser.createMethodNode(MemberSignatureParser.java:57)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode$2.get(DecompiledClassNode.java:234)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode$2.get(DecompiledClassNode.java:231)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.createMethodNode(DecompiledClassNode.java:242)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitMembers(DecompiledClassNode.java:199)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getDeclaredField(DecompiledClassNode.java:116)
> at
> org.codehaus.groovy.classgen.Verifier.getMetaClassField(Verifier.java:195)
> at
> org.codehaus.groovy.classgen.Verifier.addGroovyObjectInterfaceAndMethods(Verifier.java:411)
> at org.codehaus.groovy.classgen.Verifier.visitClass(Verifier.java:246)
> at
> org.codehaus.groovy.control.CompilationUnit$18.call(CompilationUnit.java:811)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1084)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:640)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:618)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:595)
> at
> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:401)
> at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:89)
> at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:341)
> at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:338)
> at
> org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:336)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:320)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:262)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:272)
> at groovy.lang.GroovyClassLoader$parseClass$0.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:127)
> at
> spock.util.EmbeddedSpecCompiler.doCompile(EmbeddedSpecCompiler.groovy:101)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:190)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:58)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:156)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:168)
> at
> spock.util.EmbeddedSpecCompiler.compile(EmbeddedSpecCompiler.groovy:76)
> at spock.util.EmbeddedSpecCompiler$compile.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:127)
> at spock.util.EmbeddedSpecRunner.run(EmbeddedSpecRunner.groovy:92)
> at spock.util.EmbeddedSpecRunner$run.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:127)
> at
> de.scrum_master.gitter.spock.d20210706.EmbeddedSpecRunnerTest.$spock_feature_0_0(EmbeddedSpecRunnerTest.groovy:28)
> {code}
> * Even when setting system property {{groovy.target.bytecode}} to a value
> like {{1.8}} on the command line
> * and using code fully compatible with the target bytecode level,
> * and even though the used {{GroovyClassLoader}} has a
> {{CompilerConfiguration}} with the correct {{targetBytecode}} (I checked,
> printing it before calling the script compiler),
> errors like the above occur, probably because the compiler somehow needs to
> analyse/decompile JRE classes.
> If the embedded ASM version relocated to the {{groovyjarjarasm.asm}} package
> would be upgraded to the current ASM 9.2, I think the problem should go away
> while being fully backwards compatible. I am not asking for target 16 or 17
> compilation support (even though that should in theory be possible, even
> without supporting Java 16/17 source code features), only for the compiler
> being able to at least understand existing Java 16/17 byte code. I am
> assuming this to be trivial to implement and am expecting all existing tests
> to still pass, except maybe for some negative tests testing for the above
> error message, if you have any such tests.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
