Gradle 7.4 fails on multi release jar's with JDK 19 code #24390
Comments
|
jackson-core 2.15.0-rc1 has META-INF/versions classes - most notably some in META-INF/versions/19. It seems like Gradle prior to v7.6 had an older version of asm that could not handle Java 19 classes. The question in my head is why Gradle does not ignore classes in META-INF/versions that are targeted at a Java version higher than the Java version being used to run the Gradle build. The stacktrace with Gradle 7.5.1 looks like: |
|
@yanivkr could you rename the issue that issue is associated with Gradle's instrumenting of multi-release jars? The current title makes it more likely that noone will look at the issue - that they might think it is user error as opposed to an underlying issue that might still affect gradle. A multi-release jar with support for Java 20 classes may still be a problem in latest Gradle releases - even if they appear to have fixed the issue with Java 19 classes. |
|
@yanivkr Also... I know this is asking for a lot but just in case it was possible, it'd be great to know if possible earlier Gradle versions might not have the issue (or, conversely, do have). Any additional datapoints pre-7.4 would be useful. |
yanivkr
changed the title
|
@pjfanning Renamed the issue. Can the change be backported to Gradle 7.4.X? |
|
I created a forum topic to see if I could interest any Gradle folk in this issue. https://discuss.gradle.org/t/is-there-any-way-to-skip-gradle-instrumenting-classpath-file-transformer/45213 |
|
@yanivkr Right, I get that support for JDK 19 bytecode was only added then. What I was/am wondering is whether earlier Gradle versions might have avoided the issue by not trying to process bytecode in question (sometimes earlier tool versions happen to work, not by design but by lucky omission). I wonder how easy it'd be to create something like Github action to try out if various Gradle versions (using Matrix setup) might have the issue or not. But that would be assuming something that may not be true (that is, I guess it's likely many/most older versions are affected). |
|
The title/description here sounds like Gradle can't build anything that depends on multi release jar's with JDK 19 code This is not true (!) The error appears when you use such a Jar in Gradle Plugins (or custom build logic). For example: It seems that this is already fixed in 7.6. This is kind of a normal situation for code that extends Gradle itself. I don't think there is anything left to do. It does not mean that there is a problem with building Java/Kotlin/Android/etc Applications or Libraries with such Jars. I assume that this works fine (and these are probably like 99% of the cases where e.g. Jackson is used in Gradle builds). For example: |
|
Thanks @jjohannes - that lowers the importance of the issue for Jackson users |
|
Thank you @jjohannes! I concur with @pjfanning that this sounds like much less of an issue in that case. |
mlopatkin
added
in:configuration-cache
|
@jjohannes this bug critically impacted my organization. Each of our Java projects use our internally developed Gradle plugin, which somehow got For now as a workaround we added the following code section to the I'm working on upgrading all our projects to Gradle 7.6.1, including our internally developed Gradle plugin. This is not a trivial upgrade because several of our plugin's dependencies themselves are incompatible with Gradle 7.6.1 |
|
@Toldry sorry to hear about all this trouble, and thank you for sharing it. This is very unfortunate. |
|
My understanding is that this can be an issue even on Gradle 7.6.1. Although that version supports running Gradle on JDK19, it still uses ASM 9.2, which only supports bytecode up to JDK18. So instrumentation of JDK19 classes can still fail on 7.6.1. Gradle 8.1 has updated ASM to 9.4 as part of the JDK20 support, but we should consider updating ASM for Gradle 7.x as well. |
jvalkeal
added a commit
to spring-projects/spring-shell
that referenced
this issue
Apr 28, 2023
- Upgrade gradle 7.6.1 due to gradle/gradle#24390 - Fixes #717
5 tasks
timtebeek
added a commit
to openrewrite/rewrite-kotlin
that referenced
this issue
May 4, 2023
To properly use multi release jars in plugins, as reported in Slack: https://rewriteoss.slack.com/archives/C01A843MWG5/p1683207987197019?thread_ts=1683202185.924089&cid=C01A843MWG5 gradle/gradle#24390
timtebeek
added a commit
to openrewrite/rewrite-kotlin
that referenced
this issue
May 4, 2023
To properly use multi release jars in plugins, as reported in Slack: https://rewriteoss.slack.com/archives/C01A843MWG5/p1683207987197019?thread_ts=1683202185.924089&cid=C01A843MWG5 gradle/gradle#24390
|
Let's upgrade ASM indeed for the upcoming 7.x patch release. But note that I cannot reproduce the issue at all with Gradle 7.6 or 7.6.1. The ASM version used there is already ASM 9.3. |
r3mariano
added a commit
to cashapp/wisp
that referenced
this issue
May 25, 2023
Downstream we have engineers that have run into FasterXML/jackson-core#955 and gradle/gradle#24390 (despite Gradle 7.6.1). Downgrading works around these issues until a new Gradle version that works is published.
r3mariano
added a commit
to cashapp/wisp
that referenced
this issue
May 25, 2023
Downstream we have engineers that have run into FasterXML/jackson-core#955 and gradle/gradle#24390 (despite Gradle 7.6.1). Downgrading works around these issues until a new Gradle version that works is published.
rainecp
pushed a commit
to cashapp/misk
that referenced
this issue
Jul 17, 2023
Downstream we have engineers that have run into FasterXML/jackson-core#955 and gradle/gradle#24390 (despite Gradle 7.6.1). Downgrading works around these issues until a new Gradle version that works is published.
rainecp
pushed a commit
to cashapp/misk
that referenced
this issue
Jul 19, 2023
Downstream we have engineers that have run into FasterXML/jackson-core#955 and gradle/gradle#24390 (despite Gradle 7.6.1). Downgrading works around these issues until a new Gradle version that works is published.
rainecp
pushed a commit
to cashapp/misk
that referenced
this issue
Jul 24, 2023
Downstream we have engineers that have run into FasterXML/jackson-core#955 and gradle/gradle#24390 (despite Gradle 7.6.1). Downgrading works around these issues until a new Gradle version that works is published.
rjrudin
added a commit
to marklogic/marklogic-spark-connector
that referenced
this issue
Oct 13, 2023
Avoids this bug that affects shadowJar - gradle/gradle#24390
2 tasks
|
This issue now happens with the new version of jackson-core:2.16.1 which uses JDK 21 |
The issue is resolved as of Gradle 8.4. Please follow #27156 for a potential backport to 7.6.x line. |
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When
com.fasterxml.jackson.core:jackson-core:2.15.0-rc1is in the buildscript dependencies it fails to write locks.Expected Behavior
Build should succeed
Current Behavior
Build fails with the error
Steps to Reproduce
Clone this repo and run
./gradlew buildYour Environment
Build scan URL:
cannot provide build scan
Additional notes:
2.15.0-rc1ofjackson-coreintroduces a multi-release jar [link to release notes], which is likely the reason why this error occurs on this particular version and not earlier versions.The text was updated successfully, but these errors were encountered: