GROOVY-10503: bump ASM to 9.2, making compiler work on Java 16-18 #1690
Conversation
ASM 9.2 is compatible with Java 18. So now when compiling under Java 16+, the compiler will be able to successfully analyse JDK or library files with class file versions 60-62. This helps to avoid errors coming from groovyjarjarasm.asm.ClassReader like: IllegalArgumentException: Unsupported class file major version 61 Using system property 'groovy.target.bytecode', e.g. setting it to '1.8' or '11', users can of course still compile scripts to lower byte code versions than the current JRE, but at least the compiler does not trip over those JRE files with more recent class file versions anymore.
|
There is also a file for the CI build(s) if you wish the verification to include Java 16 or 17 or 18: https://github.com/apache/groovy/pull/1683/files#diff-6ac3f79fc25d95cd1e3d51da53a4b21b939437392578a35ae8cd6d5366ca5485 Building with Java 16+ may require gradle changes -- I do have most of them worked out in a shelveset and could push it to a branch if you are interested. Groovy 3 branch also has all of these changes, but it may be difficult to tell which specific changes are meant for Java 16+ support and which are there for other reasons. Just a quick FYI, ASM 8 was only introduced 15 days ago and has not made it into a release of Groovy 2.5 yet -- I bumped from ASM 7 to 8 to keep the risk small: #1683 |
|
Also if Groovy 2.5 offers official support for Java 16+, there are a class of bugs around interface default methods that have only been fixed in Groovy 4+ that will likely be expected to be fixed. Here is one example, but I have seen this in multiple issues and possibly on the mailing list: https://issues.apache.org/jira/browse/GROOVY-10391 With this in mind, one option is to update the ASM_VERSION constant, but skip adding the JDK16, JDK17 and JDK18 constants. |
What are you talking about? This is on the Groovy 2.5 branch and my change bumped it to 9.2: Line 146 in 861ee93 Are we maybe talking about different things here? |
I answered that on Jira already. It is not about official Java 16+ support but about being able to parse class files when compiling to lower bytecode levels without tripping over Java 16+ class files from the JRE. That works just fine after my changes. Before, it did not.
Don't make the scope bigger than what I clearly described on Jira, please.
Why? After adding the constants, when compiling scripts, ASM can create class files for the corresponding versions. It does not mean that it uses any specific features from those versions. They are basically Java 15 (or lower) class files with higher version numbers. No harm done. |
Yes, 15 days ago ASM was increased from 7 to 8 on 2_5_X branch. I chose to hold back from ASM 9 to lower the risk. There has not been a Groovy 2.5 release since then, so there is no release that includes Java 15 target support (aka ASM 8) yet. 2.5.16 was my goal for that.
I'm trying to limit the scope of this change. Adding the |
Be more specific in the javadocs for * CompilerConfiguration.JDK16, * CompilerConfiguration.JDK17, * CompilerConfiguration.JDK18, adding the following sentence to each of them: Use it at your own risk, because JDK 18 is not officially supported in this Groovy release yet.
|
FWIW, ASM 9.3 with Java 19 support was released yesterday. |
Yes, I got the release e-mail, too. But without encouragement by @eric-milles or another project maintainer here, I would rather not extend the PR to encompass ASM 9.3 and Java 19 yet, because Eric was already skeptical about 9.2 and e.g. did not merge the PR before the 2.5.16 release. Maybe 2.5.17? I am not sure. But of course, I could easily bump to 9.3, not expecting any incompatibilities. The tests remained green without any changes after the bump to 9.2, too. So I am waiting for feedback. |
This PR fixes
GROOVY-10503.ASM 9.2 is compatible with Java 18. So now when compiling under Java 16+, the compiler will be able to successfully analyse JDK or library files with class file versions 60-62. This helps to avoid errors coming from
groovyjarjarasm.asm.ClassReaderlike:Using system property
groovy.target.bytecode, e.g. setting it to1.8or11, users can of course still compile scripts to lower byte code versions than the current JRE, but at least the compiler does not trip over those JRE files with more recent class file versions anymore.