[
https://issues.apache.org/jira/browse/GROOVY-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496414#comment-17496414
]
Alexander Kriegisch edited comment on GROOVY-10503 at 2/23/22, 12:56 AM:
-------------------------------------------------------------------------
[~paulk], of course that is up to a project maintainer like you to decide. I
just do not understand why you cannot release and declare Java 15 support and
state in the release notes that
* 2.5.16 is prepared to also read Java 16+ class files,
* but not officially supported on production environments and
* users can use it at their own risk.
That would certainly be better than using an outdated ASM version on purpose to
trip up users, so they cannot even use JDK 16+ at their own risk.
Some background for you: I have used 2.5.14 (no typo!) on Java 15 already for a
while and had no problems. The reason why I did not bump Groovy to 3 is that
the tests are still on Spock 1.3 and some use JUnit 4 stuff like runners. The
only thing which was not working correctly on JDK 16+ was dynamic code
compilation using {{EmbeddedSpecRunner}} due to the often-seen
{{groovyjarjarasm.asm.ClassReader}} problems which also hinder IntelliJ IDEA
from compiling some classes. So I bumped to 2.5.15 first, to no avail. With my
PR, those problems simply go away in Maven and the project runs just fine on
JDKs 16 and 17. If IDEA would also bump to a more recent Groovy compiler
version, which is due for the next release in March, the problem should go away
there, too. I simply scratched my own itch and solved the problem.
I cannot understand why you would want to miss the chance to get early user
feedback for those platforms, before you decide if you want to fully support it
in later 2.5 releases or save the full support for Groovy 3 and 4. FWIW, the CI
build shows that all of Groovy's own tests also pass for classic and indy.
Bytecode engineering tools like Byte Buddy rely on ASM 9.2, AspectJ (to which I
contribute) does too. Are you afraid that the version bump introduces new
problems to Groovy? If so, can you write tests exposing them, if the current
test suite does not uncover them?
was (Author: kriegaex):
[~paulk], of course that is up to a project maintainer like you to decide. I
just do not understand why you cannot release and declare Java 15 support and
state in the release notes that
* 2.5.16 is prepared to also read Java 16+ class files,
* but not officially supported on production environments and
* users can use it at their own risk.
Some background for you: I have used 2.5.14 (no typo!) on Java 15 already for a
while and had no problems. The reason why I did not bump Groovy to 3 is that
the tests are still on Spock 1.3 and some use JUnit 4 stuff like runners. The
only thing which was not working correctly on JDK 16+ was dynamic code
compilation using {{EmbeddedSpecRunner}} due to the often-seen
{{groovyjarjarasm.asm.ClassReader}} problems which also hinder IntelliJ IDEA
from compiling some classes. So I bumped to 2.5.15 first, to no avail. With my
PR, those problems simply go away in Maven and the project runs just fine on
JDKs 16 and 17. If IDEA would also bump to a more recent Groovy compiler
version, which is due for the next release in March, the problem should go away
there, too. I simply scratched my own itch and solved the problem.
I cannot understand why you would want to miss the chance to get early user
feedback for those platforms, before you decide if you want to fully support it
in later 2.5 releases or save the full support for Groovy 3 and 4. FWIW, the CI
build shows that all of Groovy's own tests also pass for classic and indy.
Bytecode engineering tools like Byte Buddy rely on ASM 9.2, AspectJ (to which I
contribute) does too. Are you afraid that the version bump introduces new
problems to Groovy? If so, can you write tests exposing them, if the current
test suite does not uncover them?
> 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)
