java.lang.NoClassDefFoundError: kotlin/jvm/JvmInline

[ChenZheOnePiece]

I hope to support both Java and kolitin in my project, but Jackson module kotlin is introduced into my POM. In the Java environment, this package will report errors

java.lang.NoClassDefFoundError: kotlin/jvm/JvmInline
	at com.fasterxml.jackson.module.kotlin.ExtensionsKt.isUnboxableValueClass(Extensions.kt:122) ~[jackson-module-kotlin-2.13.0.jar:2.13.0]
	at com.fasterxml.jackson.module.kotlin.KotlinSerializers.findSerializer(KotlinSerializers.kt:69) ~[jackson-module-kotlin-2.13.0.jar:2.13.0]
	at com.fasterxml.jackson.databind.ser.BeanSerializerFactory._createSerializer2(BeanSerializerFactory.java:215) ~[jackson-databind-2.13.0.jar:2.13.0]
	at com.fasterxml.jackson.databind.ser.BeanSerializerFactory.createSerializer(BeanSerializerFactory.java:173) ~[jackson-databind-2.13.0.jar:2.13.0]
	at com.fasterxml.jackson.databind.SerializerProvider._createUntypedSerializer(SerializerProvider.java:1495) ~[jackson-databind-2.13.0.jar:2.13.0]
	at com.fasterxml.jackson.databind.SerializerProvider._createAndCacheUntypedSerializer(SerializerProvider.java:1443) ~[jackson-databind-2.13.0.jar:2.13.0]
	at com.fasterxml.jackson.databind.SerializerProvider.findContentValueSerializer(SerializerProvider.java:777) ~[jackson-databind-2.13.0.jar:2.13.0]

[dinomite]

Hmm, do you have the Kotlin stdlib for the JDK (e.g. kotlin-stdlib-jdk8) as a dependency of your project?

[stepbeekio]

I've encountered the same thing on upgrading from Spring Boot 2.4.x to 2.6.1.

Upgrading from kotlin version 1.4.0 to 1.6.0 fixed this for me weirdly. I've not had time to figure out why.

[k163377]

My guess is that it is due to a combination of Kotlin versions.

JvmInline is a class introduced in Kotlin 1.5. Since jackson-module-kotlin is Kotlin 1.5 since 2.13, I think that using 2.12 series will solve the problem.

[dinomite]

@stepbeekio @ChenZheOnePiece Can either of you confirm @k163377 's hypothesis?

[JLLeitschuh]

What are the Kotlin compatibility guarantees offered by this library? I'm not finding anything in the README about this. From what I can tell, the latest version of the library isn't compatible with Kotlin 1.3.

[JLLeitschuh]

I did just attempt to compile this library with Kotlin 1.3 compatibility. I was willing to modify the JvmInline check to be reflection based, but it looks like all the unsigned types are also being used too. As such I don't think that supporting Kotlin 1.3 would be easily possible without breaking out the Kotlin 1.5 support stuff out into an independent library. Personally I don't have the time to do this. For now, I'm just relying upon 2.12.3 of this library in order to be backwards compatible with Kotlin 1.3

[dinomite]

@JLLeitschuh We don't have guarantees listed anywhere, though you're right that we should. 2.12 was built against Kotlin 1.4.x and 2.13 uses 1.5.x.

[cowtowncoder]

It would be great if there was a contribution for running something that would cross-check version compatibilities (specific kotlin core, specific Jackson minor version), as a matrix. While automation like Github Actions would be nice -- and actually might make matrix testing easier, come to think of it now -- even one-off script could work.

I have sometimes done investigation for example for Guava module/Guava compatibility:

https://cowtowncoder.medium.com/jackson-guava-compatibility-b0b61ac59b28

but it's maybe bit too manual approach, using

https://github.com/cowtowncoder/jackson-compat-minor

which is sort of designed for tests, but mostly for Jackson core / Jackson module dimension.

Alternatively we could just rely on community, asking for reports on combinations that are known to work (or to NOT work). I know that is not optimal but it might be a good way to still reduce the need for everyone to investigate this on their own.

[JLLeitschuh]

I was thinking about doing all of this, but it would involve splitting the base project into two separate projects. Totally doable, but more difficult to do with Maven IMHO. Using Gradle could significantly simplify this.

[cowtowncoder]

Which base project would you be thinking of here? I would not suggest doing this for Kotlin module itself (f.ex).

At any rate, the idea of external integration test project seems useful but I have not had much time to spend on figuring out good ways to do it -- would love to get help, give access, ownership wherever needed. To me compatibility aspects are amongst biggest challenges Jackson has, due to its popularity, modular components.

[JLLeitschuh]

I was thinking about potentially just using Gradle as the cross-version testing tool, but leaving all your publishing infrastructure in place using Maven. I don't really want to mess with that personally.

[JLLeitschuh]

PR Here: https://github.com/FasterXML/jackson-module-kotlin/pull/534

[k163377]

This issue is closed because Kotlin 1.4 is already deprecated. https://kotlinlang.org/docs/kotlin-evolution.html#compatibility-flags https://kotlinlang.org/docs/maven.html#attributes-common-to-jvm-and-js

[cowtowncoder]

@k163377 Kotlin module still officially supports Kotlin 1.4 as per README; at least for Jackson 2.14.

But if we decide explicitly NOT to support it, we should probably indicate this in README (wrt 2.15.0), as well as in main Jackson 2.15 release notes:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15

And also, if so, remove testing against Kotlin-core 1.4 in matrix build for CI.

I have no strong feeling wrt this, but I think we'd need to:

1. Ask about this either on jackson-dev or maybe jackson-users and
2. Create a Github issue proposing removing Kotlin 1.4 support from jackson-module-kotlin 2.15

I don't expect this to be very controversial, but there should be a decision to do that since it seems like Kotlin 1.4 is still nominally supported.

[cowtowncoder]

Created #632 for official dropping of support; sent an email to jackson-dev asking for feedback.

[k163377]

Kotlin module still officially supports Kotlin 1.4 as per README; at least for Jackson 2.14.

I closed this because it is not practical to work on fixing issues related to the already deprecated Kotlin 1.4, but I didn't think it should be a priority as far as updating the documentation. I will be careful from now on.

[cowtowncoder]

@k163377 I have no objections to closing the issue, or deprecating support -- but what I meant was that this module HASN'T yet (at least officially) dropped Kotlin 1.4 support. But I think we should.

Put another way: it's all good; I hope we can make everything align here so that Kotlin 1.4 (which is unsupported by its creators, right?) is also no longer supported by new versions of Jackson Kotlin module. But it is important to document when support changes; just because IDEA changes status of kotlin-core does not automatically change things on our end (and conversely we can be more aggressive in dropping support if need be).

Anyway: I think it's good finding at any rate. There has been discussion about support level, but no decisions. No we should be able to decide.