Caused by: java.util.concurrent.ExecutionException: org.gradle.api.GradleException: Failed to create Jar file /Users/***/.gradle/caches/jars-9/1bb26d34e98b715e3c3f4623ed2597f7/jackson-core-2.15.0-rc1.jar.
at org.gradle.internal.UncheckedException.unchecked(UncheckedException.java:74)
... 133 more
Caused by: org.gradle.api.GradleException: Failed to create Jar file /Users/***/.gradle/caches/jars-9/1bb26d34e98b715e3c3f4623ed2597f7/jackson-core-2.15.0-rc1.jar.
at org.gradle.internal.classpath.ClasspathBuilder.jar(ClasspathBuilder.java:55)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.instrument(InstrumentingClasspathFileTransformer.java:137)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.transform(InstrumentingClasspathFileTransformer.java:132)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.transform(InstrumentingClasspathFileTransformer.java:96)
at org.gradle.internal.classpath.DefaultCachedClasspathTransformer.transformFile(DefaultCachedClasspathTransformer.java:193)
at org.gradle.internal.classpath.DefaultCachedClasspathTransformer.lambda$cachedFile$6(DefaultCachedClasspathTransformer.java:186)
at org.gradle.internal.UncheckedException.unchecked(UncheckedException.java:74)
at org.gradle.internal.classpath.DefaultCachedClasspathTransformer.lambda$transformAll$9(DefaultCachedClasspathTransformer.java:233)
... 2 more
Caused by: java.io.IOException: Failed to process the entry 'META-INF/versions/19/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class' from '/Users/***/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-core/2.15.0-rc1/9ae58902c963235ff1033d192043fac922b981fb/jackson-core-2.15.0-rc1.jar'
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.lambda$visitEntries$1(InstrumentingClasspathFileTransformer.java:161)
at org.gradle.internal.classpath.ClasspathWalker.visitJarContents(ClasspathWalker.java:91)
at org.gradle.internal.classpath.ClasspathWalker.visit(ClasspathWalker.java:55)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.visitEntries(InstrumentingClasspathFileTransformer.java:148)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.lambda$instrument$0(InstrumentingClasspathFileTransformer.java:139)
at org.gradle.internal.classpath.ClasspathBuilder.buildJar(ClasspathBuilder.java:66)
at org.gradle.internal.classpath.ClasspathBuilder.jar(ClasspathBuilder.java:53)
... 9 more
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 63
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:199)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:180)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.lambda$visitEntries$1(InstrumentingClasspathFileTransformer.java:151)
... 15 more
I think some classes do NOT work well with JDK17.
This has nothing to do with jackson - try cleaning your gradle cache. Even just delete that .gradle/caches dir.
Gradle can always hit issues with this, caching internet files is hard to get right - you cannot guarantee 100% success with downloading files.
Have you tried downloading the reproducing project? this is not a cache issue but rather a JDK version issues as mentioned in the comment above. Something not working properly with the multi release jar
upgrading Gradle does eliminate the issue, but my project is constrained and cannot upgrade the Gradle version
So don't upgrade jackson then. There is no real constraint not to update - just some management issue that is not my concern.
I am concerned: if 2.15 does not work with relatively recent Gradle versions, we do have a problem.
I don't like the idea of requiring very recent build tools where there is no solid reason to do so (we are not adding anything that would benefit from newer Gradle versons), other than avoid breakage we may have introduced.
I was wondering about safety of multi-version jars, and especially so for the most important piece of Jackson, jackson-core.
Unfortunately I don't have enough Gradle knowledge to know what might be happening here, or how to help. I wouldn't want to start removing classes for later JDKs, but that seems like it might be one option.
This is a bug in Gradle - gradle/gradle#24390
Why Gradle team are running asm and looking at every class file in the jar is beyond me.
multi-release jars have been around since Java 9 - why Gradle doesn't just ignore classes in the META-INF/versions that are for versions higher than the Java runtime being used - this is very strange - Java runtime itself does this
not being robust around asm jar versions is a major issue for Gradle - new Java versions come out every 6 months and the Gradle team need to learn to skip over the classes in META-INF/versions that asm can't handle
If the Jackson team are to worry about old versions of Gradle, I really don't know where to go.
possibly best to abandon fastdoubleparser support altogether - it probably isn't widely used
it might be possible to hack the maven-shade-plugin usage in jackson-core to strip out the META-INF/versions/19 files - these are the most likely to be leading to this issue - this would need testing
go further with the maven-shade-plugin usage in jackson-core and strip out all files in META-INF/versions and this would need testing
I don't know if Gradle team will look at gradle/gradle#24390 - it's possible that they will backport the Gradle 7.6 fix - but I suspect it is unlikely.
I must admit to being reluctant to volunteer time on this. I feel strongly that this is a bug in Gradle and one that has been fixed to boot.
Ok. Did not realize it's a bona fide bug in gradle, only surprised it'd be present in a relatively recent version.
My concern is simply this: Jackson is Java 8 compatible so it has to work with Java 8 tools, in general. Not every version everywhere of course.
But looking at https://en.wikipedia.org/wiki/Gradle version 7.6 is really rather new -- and if older versions have issues, we might have situation where Jackson 2.15 would be as good as broken for Gradle users. This is not really acceptable.
I don't see it as "old version" in grand scheme of things: companies I've worked for have had years behind latest version of tools, esp. Gradle (due to Gradle itself moving rather fast... longer story wrt backwards-compatibility, lack thereof, and some bad usage by company itself).
But maybe this is not the case -- I might be seeing catastrophe where there isn't one.
If we had someone who could test this, I'd probably consider stripping out of JDK 19 support if that would work around issues for Java 17.
I guess the biggest question really is "how big a problem is this" wrt users -- is it for all JDKs pre-19, for Gradle 7.6 or before? Specific Gradle version? Just some JDKs? (wrt which versions gradle woud peek to).
Not really sure how to go about gathering that information. But at least there's this issue for devs to find.
So far, it looks like old versions of Gradle use an old version of asm and tries to analyse META-INF/versions classes that it shouldn't. It seems newer versions of Gradle have fixed the issue. Please use newer versions of Gradle (7.6.1 and 8.0.2 do not hit the issue in the sample).
I agree with your comments including the below.
It is not a problem of jackson.
could use newer Gradle, or not upgrade jackson.
@pjfanning Was wondering about same thing. I guess it'd be great to update title/description to clarify that this does not affect builds where jackson-core is just a dependency.
But either way, fix here then being to use a more recent Gradle version: it seems reasonable for more advanced Gradle usage (where jackson-core is used by Gradle plug-ins?).
jackson-core:2.15.0-rc1 causes Gradle build failure
jackson-core:2.15.0-rc1 causes Gradle (pre-7.6) build failure
Mar 22, 2023
Resolution: if affected, upgrade to Gradle 7.6.1 or later.
As per comment gradle/gradle#24390 (comment) should NOT affect basic dependency resolution.
Closing.
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.
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.
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.
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.
This requires (temporarily?) removing the Gradle linter plugin we use
due to some mysterious incompatibility that I don't understand, however
it fixes the issue with Jackson dependencies that we were seeing
similarly to FasterXML/jackson-core#955
This requires (temporarily?) removing the Gradle linter plugin we use
due to some mysterious incompatibility that I don't understand, however
it fixes the issue with Jackson dependencies that we were seeing
similarly to FasterXML/jackson-core#955
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.
