Kotlin object deserialization with @JsonCreator fails in Jackson 2.18.0
#841
Comments
Running Parcelo in a container via our current Dockerfile revealed that "uses-sdk" fields were not being parsed from applications' Android manifests, effectively preventing app uploads since the targetSdk property of uses-sdk is required by Parcelo. This bug wasn't caught until now because it only seems to manifest itself when running via the Dockerfile; running locally as in our recommended development environment does not have the issue. The Jackson 2.18.0 upgrade has not yet been included in a production release, so it's uncertain whether the issue would have surfaced in our production environment. We tracked the issue down to a regression in Jackson 2.18.0. The exact cause is unknown. However, a number of seemingly related issues were reported for Jackson 2.18.0 [1], so we plan to closely monitor those issues and test upcoming Jackson releases carefully to prevent breakage. [1]: See below: - FasterXML/jackson-module-kotlin#841 - FasterXML/jackson-module-kotlin#842 - FasterXML/jackson-module-kotlin#843 - FasterXML/jackson-module-kotlin#832 - FasterXML/jackson-databind#4508 - FasterXML/jackson-databind#4752
|
@cowtowncoder |
|
@k163377 Although number of changes for 2.18 is big enough that I don't have full recollection, but I don't think I made any changes targeting that method. But @JooHyukKim did work on better support for any setters and that could have resulted in changes in this class One more question -- is there any change between 2.18.0 and current One last thing: this late-stage change for 2.18.0 could be relevant here: FasterXML/jackson-databind#4688 (via PR FasterXML/jackson-databind#4689 ) |
Running Parcelo in a container via our current Dockerfile revealed that "uses-sdk" fields were not being parsed from applications' Android manifests, effectively preventing app uploads since the targetSdk property of uses-sdk is required by Parcelo. This bug wasn't caught until now because it only seems to manifest itself when running via the Dockerfile; running locally as in our recommended development environment does not have the issue. The Jackson 2.18.0 upgrade has not yet been included in a production release, so it's uncertain whether the issue would have surfaced in our production environment. We tracked the issue down to a regression in Jackson 2.18.0. The exact cause is unknown. However, a number of seemingly related issues were reported for Jackson 2.18.0 [1], so we plan to closely monitor those issues and test upcoming Jackson releases carefully to prevent breakage. [1]: See below: - FasterXML/jackson-module-kotlin#841 - FasterXML/jackson-module-kotlin#842 - FasterXML/jackson-module-kotlin#843 - FasterXML/jackson-module-kotlin#832 - FasterXML/jackson-databind#4508 - FasterXML/jackson-databind#4752
|
FYI, the mentioned any-setter job is as follows Also, I will also try to look into the solution, to figure out solution. Won't be so soon tho. |
|
For testing, what may help slightly is the release of 2.18.1 (happening now), can avoid use of SNAPSHOT versions (except for fixes that go in 2.18 branch from now on etc). |
First ObservationFirst, this is where call paths diverges (between 2.17 and 2.18).
Below is the method in question. 
Second ObservationAnother thing is that hitting ... ((KotlinValueInstantiator) BeanDeserializer._valueInstantiator)._defaultCreator... on IntelliJ debugger returns in versions...
AssumptionsLooking at WDYT? |
|
Issue submitted to This issue needs to be fixed in |
|
Hmmmh. I am not yet fully convinced that 2.17 behavior is more correct than 2.18. a. Represent either 0-argument Constructor or 0-argument Factory method (2.17) If we can revert/change handling to (a) without breaking any tests, that would seem preferable. Now: why does this change break Kotlin module? Is it calling 0-args constructor somehow, instead of factory method? I'll have a look at the new |
This is because The location where this path change is occurring is explained in @JooHyukKim 's comment. |
|
@k163377 Ok; conceptually that call should be legal (as in, handling it like arguments-taking Creators should work the same way), but I agree it is at least sub-optimal: 0-args factory method cannot take any arguments so there is no need to go through the usual complications of buffering etc. So I think ideally we'd figure out how to keep 0-args factory method as special case that does not go through regular properties-based-creator handling. If that is not possible, Kotlin module should probably be changed to handle this case (whether it considers 0-args special or not). |
Search before asking
Describe the bug
In Jackson 2.17 and earlier,
objectwhich implements a@JsonCreator @JvmStatic fun deserialize()function serializes and deserializes successfully. After upgrading to Jackson 2.18.0 it fails.To Reproduce
Expected behavior
Test passes with stdout (that’s the behaviour with Jackson 2.17.0):
Instead what happens with 2.18.0 is the test fails with:
Test output
and stdout – showing that it got correctly serialized to empty object, but
@JsonCreatornever gets called:Versions
Kotlin: 2.0.21
Jackson-module-kotlin: 2.18.0
Jackson-databind: 2.18.0
Additional context
Perhaps related to FasterXML/jackson-databind#4742 (but here it’s a simple
objectin Kotlin instead).The text was updated successfully, but these errors were encountered: