Closed jeremylong closed 10 months ago
Thank you for your interest in Gradle!
This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.
This has been fixed in Gradle 8.4 through https://github.com/gradle/gradle/issues/25434.
@gradle/bt-configuration Should we keep this issue open because backporting the fix is possible to a future 7.6.x release? If not this issue should be closed and the milestone removed.
The original fix is big enough to doubt backporting, but we can at least bump the ASM version for the 7.6 line.
@mlopatkin bumping the version of ASM may be enough to resolve the issue we are facing.
Seeing this issue as well and proving very hard to work around... (as is updating to Gradle 8), a backport to 7.6 would be very much welcome.
I'm unsure if Gradle team will backport fixes for every new Java version. Can we have some generalized solution? Like skipping all unsupported META-INF/versions/*
?
This issue is absolutely wrecking us. Some context about our situation:
Jackson 2.16.1's jackson-core
library is a multi-release jar containing a Java 21 (class file major version 65) class:
META-INF/versions/21/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class
When this library is used in a plugin classpath on Gradle 7.6.3, the asm
library that Gradle has bundled is unable to read this classfile and errors out, failing the build:
We're in a risky situation: we may need to upgrade to Jackson 2.16.1 at any moment in order to satisfy compliance requirements around security vulnerabilities, but cannot upgrade it due to most repos still being on Gradle 7. We are trying to move to Gradle 8 but it is taking a very long time. We've actually had to roll back Jackson upgrades over all our products/libraries/gradle plugins because of this issue.
Any sort of backport that helps this situation would be greatly appreciated:
asm
would get us out of the immediate danger and give us more time to complete the Gradle 8 migration.I think the only reasonable way to resolve this is a backport. Please can you forward this request onto the relevant team for us?
Fixed via #27633
Related issue about incremental compilation on projects containing Java 21 classes in mult-release jars
@mlopatkin @bamboo and the rest of the gradle team - Thank You! I was finally able to test this out and my builds are working again with multi-release JARs. I really appreciate all the work.
Current Behavior
If I apply a plugin that uses H2 ('com.h2database:h2:2.2.224'), a multi-release JAR, the execution of the plugin fails.
I then run
./gradlew dependencyCheckAnalyze
I get the following error/stacktrace:Expected Behavior
The execution of the gradle plugin/task should succeed (well, in the case of dependency-check it might fail for other reasons). However, a plugin using a multi-release JAR should be able to be executed.
Context (optional)
This may be related to #24390 and #24515.
I am the author of the dependency-check plugin which is downloaded from central over 1 million times per month. We upgraded h2 so our user base would no longer ask about CVE-2022-45868.
Steps to Reproduce
provided above
Gradle version
7.6.3
Build scan URL (optional)
No response
Your Environment (optional)
No response