Missing empty constructor issue: deserialization breaking change from 2.17 to 2.18 #846

baylrock · 2024-11-09T05:18:15Z

Search before asking

I searched in the issues and found nothing similar.
I have confirmed that the same problem is not reproduced if I exclude the KotlinModule.
I searched in the issues of databind and other modules used and found nothing similar.
I have confirmed that the problem does not reproduce in Java and only occurs when using Kotlin and KotlinModule.

Describe the bug

It appears that 2.18 introduced a change to the constructor detection, causing existing use cases to fail. I observed it in a case where a class extending a Map without an empty constructor can no longer be instantiated. See the test case example.

To Reproduce

With jackson 2.18.0 onboard:

    @Test
    fun test() {
        assertThrows<MissingKotlinParameterException> {
            jacksonObjectMapper().readValue<Old>("""{ "key":"value" }""")
        }

        assertDoesNotThrow {
            jacksonObjectMapper().readValue<New>("""{ "key":"value" }""")
        }
    }

    // what was working prior to 2.18
    class Old : TreeMap<String, String> {
        constructor(map: Map<String, String>) : super(map)
    }

    // what has to be changed to work with 2.18
    class New : TreeMap<String, String> {
        constructor() : super()
        constructor(map: Map<String, String>) : super(map)
    }

Expected behavior

Changes should be backward-compatible per the versioning standard (minor version changed).

Versions

Kotlin:
Jackson-module-kotlin: 2.18.0
Jackson-databind: 2.18.0

Additional context

I'm not 100% sure if this is a Kotlin module issue or not, as I operate in Kotlin codebase only and not invested enough to test it in plane java.
Generally, the fix to the issue is simple; the questionable part is that, if this is intentional, this is technically a breaking change in a minor version change.

cowtowncoder · 2024-11-09T18:47:38Z

Needs to be checked against 2.18.1 at least (ideally also 2.18.2-SNAPSHOT, build from 2.18 branch, but that's optional) as there are multiple relevant jackson-databind fixes.

fischl-viesure · 2024-11-14T10:46:39Z

I can confirm the bug with these versions of jackson-module-kotlin:

2.18.1
2.18.2-SNAPSHOT (commit 9889989)

I also tested with version 2.17.2 and the behavior to assure that the MissingKotlinParameterException is not thrown with the older version, as described.

k163377 · 2024-11-16T09:05:06Z

The root cause of this also seemed to be the same as #841 (FasterXML/jackson-databind#4777).

I first checked how the Old constructor is handled in KotrinamesAnnotationIntrospector and both were determined to be creator with mode=DEFAULT.
To be precise, 2.17 uses findCreatorAnnotation and 2.18 uses findDefaultCreator, but since the mode is the same, there is probably no difference.

On the other hand, as a result of StdValueInstantiator.createFromObjectSettings now registering withArgsCreator, valueInstantiator.canCreateFromObjectWith now returns true.
This changes the processing path of MapDeserializer.deserialize, causing KotlinValueInstantiator.createFromObjectWith to be called unexpectedly, resulting in an error.

cowtowncoder · 2024-11-17T03:59:59Z

@baylrock Please include actual exception message (with at least some of the stack trace).

cowtowncoder · 2024-11-17T04:00:18Z

It looks like intent was for Constructor to use "Delegating" mode; and if so perhaps it is necessary to use annotation

@JsonCreator(mode = JsonCreator.Mode.DELEGATING)

since I don't see any good heuristics for databind to determine this intent (constructor parameter name and underlying property. Not sure why in 2.17 that would be mode selected.

EDIT: Actually, I do have a guess. Perhaps it is due to type of single-argument being Map, tilting heuristics toward delegating.

baylrock · 2024-11-17T19:36:30Z

@cowtowncoder issue was found when migrating from 2.12 to 2.18. So it shouldn't be about 2.17 being weird.

cowtowncoder · 2024-11-17T23:50:01Z

@baylrock That is assuming behavior as of 2.17 was correct, which while not unreasonable assumption is not always true. In case of refactoring of property introspection for 2.18, logic was rewritten to address actual flaws for some well-known cases, but making sure all unit tests pass. Problem here is that there is an unlimited number of combinations, edge cases, and so coverage is always incomplete. While case presented here is not very complex, it seems likely it wasn't covered, and change in logic was not detected.

The question, then, is which of behaviors is more correct: that of 2.17, or that of 2.18.
Put another way: just because 2.17 behaves in certain way is not a guarantee it is the intended ("correct") way.

Having said that, I do now have one idea wrt why Creater mode heuristics may have changed with 2.18 -- I vaguely remember there being some logic to consider some types (specifically Map) as indicating preference towards choosing Mode.DELEGATING.

But with all of this said: I would suggest adding explicit

@JsonCreator(mode = JsonCreator.Mode.DELEGATING)

(with whatever mechanism Kotlin requires)
for the intended Constructor. That will eliminate any need to use heuristics on work with any 2.x version o Jackson.

fischl-viesure · 2024-11-18T07:23:32Z

@baylrock Please include actual exception message (with at least some of the stack trace).

I take the liberty and step in for baylrock, 'cause I just happened to see the updates to this ticket now.

This is the exception when instantiating class Old with version 2.18.2:

com.fasterxml.jackson.module.kotlin.MissingKotlinParameterException: Instantiation of [map type; class JacksonTest$Old, [simple type, class java.lang.String] -> [simple type, class java.lang.String]] value failed for JSON property map due to missing (therefore NULL) value for creator parameter map which is a non-nullable type
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 17] (through reference chain: JacksonTest$Old["N/A"]->JacksonTest$Old["map"])

	at com.fasterxml.jackson.module.kotlin.KotlinValueInstantiator.createFromObjectWith(KotlinValueInstantiator.kt:97)
	at com.fasterxml.jackson.databind.deser.impl.PropertyBasedCreator.build(PropertyBasedCreator.java:214)
	at com.fasterxml.jackson.databind.deser.std.MapDeserializer._deserializeUsingCreator(MapDeserializer.java:711)
	at com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:432)
	at com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:32)
	at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
	at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4917)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3860)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3843)
	at JacksonTest.test(JacksonTest.kt:34)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)

Also, annotating the constructor, as you described, with…

@JsonCreator(mode = JsonCreator.Mode.DELEGATING)

…made the exception go away 🥳 (anyway, my problem turned out to not being the one described here 😊).

Thank you cowtowncoder for helping us along!

rafalh · 2025-01-09T15:23:40Z

I've stepped onto this issue too, but in a slightly different case. I assume the root cause is the same.
This test shows the change of behavior:

data class MapWrapper1 @JsonCreator constructor(private val m: Map<String, String>) {
    val foo by m
}
data class MapWrapper2(private val m: Map<String, String>) {
    val foo by m
}
class JacksonKotlinTest {
    private val objectMapper = jacksonObjectMapper()
    private val json = """{"foo": "a", "bar": "b"}"""

    @Test
    fun test1() {
        val v = objectMapper.readValue(json, MapWrapper1::class.java)
        assertEquals("a", v.foo)
    }

    @Test
    fun test2() {
        val v = objectMapper.readValue(json, MapWrapper2::class.java)
        assertEquals("a", v.foo)
    }
}

test1 always passes. test2 passes in Jackson 2.17 and fails in Jackson 2.18.
Please note that I don't have to set the mode in @JsonCreator to DELEGATING and instead keep it as the default (DEFAULT).

The question, then, is which of behaviors is more correct: that of 2.17, or that of 2.18.

I am wondering the same. It seems the current behavior is more in line with pure Jackson without Kotlin module. I've tested normal Java classes and records and in both versions they failed to deserialize if there was no @JsonCreator annotation.

Anyway, it's a bit counter-intuitive that @JsonCreator(Mode.DEFAULT) is not implicit. I would assume this annotation is only needed if there are more than one constructor or if I want a non-default mode. Default mode is documented: "DEFAULT means that caller is to use standard heuristics for choosing mode to use.". For some reason Jackson doesn't use that standard heuristics in the case above (single constructor with Map parameter).

If the current behavior of 2.18 is considered valid, it should probably be documented as a breaking change in 2.18 to help people migrate.

cowtowncoder · 2025-01-09T17:08:32Z

Quick note: missing @JsonCreator is very different from @JsonCreator(mode = DEFAULT) -- latter indicates annotated Constructor/Factory method is explicitly to be used. Missing @JsonCreator means it won't be, unless auto-detection kicks in (when no Creator is annotated and there's just one viable candidate).

Not sure that helps untangle the issue but thought I'll mention it.

aishanand · 2025-01-15T22:58:27Z

We upgraded to spring boot 3.4 that uses jackson-core 2.18.0 and the existing code broke with the error. When will this issue be fixed?? It's forcing all the applications that went through upgrade to have the empty constructors only work fine :(

https://github.com/aishanand/personal- Github code space to recreate the issue

Exception in thread "main" java.lang.IllegalArgumentException: Cannot construct instance of com.jackson.issue.deserialize.dto.FruitDTO(although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('{"name":null,"flavorDTO":{"color":"yellow","taste":"sweet","smell":{"smellsGood":true}}}') at [Source: UNKNOWN; byte offset: #UNKNOWN] at com.fasterxml.jackson.databind.ObjectMapper._convert(ObjectMapper.java:4636) at com.fasterxml.jackson.databind.ObjectMapper.convertValue(ObjectMapper.java:4567) at com.jackson.issue.deserialize.DeserializeApplication.main(DeserializeApplication.java:18) Caused by: com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance ofcom.jackson.issue.deserialize.dto.FruitDTO (although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('{"name":null,"flavorDTO":{"color":"yellow","taste":"sweet","smell":{"smellsGood":true}}}') at [Source: UNKNOWN; byte offset: #UNKNOWN] at com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63) at com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1754) at com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1379) at com.fasterxml.jackson.databind.deser.std.StdDeserializer._deserializeFromString(StdDeserializer.java:311) at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromString(BeanDeserializerBase.java:1592) at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeOther(BeanDeserializer.java:197) at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:187) at com.fasterxml.jackson.databind.ObjectMapper._convert(ObjectMapper.java:4631)

[Note:https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.4-Release-Notes that uses 2.18.0]

cowtowncoder · 2025-01-15T23:00:23Z

Have you tried 2.18.2?

…

On Wed, Jan 15, 2025 at 2:58 PM aishanand ***@***.***> wrote: We upgraded to spring boot 3.4 that uses jackson-core 2.18.0 and the existing code broke with the error. When will this issue be fixed?? It's forcing all the applications that went through upgrade to have the empty constructors only work fine :( https://super-duper-giggle-97gv6p6x5ggf9pgp.github.dev/ - Github code space to recreate the issue Exception in thread "main" java.lang.IllegalArgumentException: Cannot construct instance of com.jackson.issue.deserialize.dto.FruitDTO(although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('{"name":null,"flavorDTO":{"color":"yellow","taste":"sweet","smell":{"smellsGood":true}}}') at [Source: UNKNOWN; byte offset: #UNKNOWN] at com.fasterxml.jackson.databind.ObjectMapper._convert(ObjectMapper.java:4636) at com.fasterxml.jackson.databind.ObjectMapper.convertValue(ObjectMapper.java:4567) at com.jackson.issue.deserialize.DeserializeApplication.main(DeserializeApplication.java:18) Caused by: com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance ofcom.jackson.issue.deserialize.dto.FruitDTO (although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('{"name":null,"flavorDTO":{"color":"yellow","taste":"sweet","smell":{"smellsGood":true}}}') at [Source: UNKNOWN; byte offset: #UNKNOWN] at com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63) at com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1754) at com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1379) at com.fasterxml.jackson.databind.deser.std.StdDeserializer._deserializeFromString(StdDeserializer.java:311) at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromString(BeanDeserializerBase.java:1592) at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeOther(BeanDeserializer.java:197) at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:187) at com.fasterxml.jackson.databind.ObjectMapper._convert(ObjectMapper.java:4631) image.png (view on web) <https://github.com/user-attachments/assets/04f15613-61b4-4790-b280-0ea4e8a31202> [Note: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.4-Release-Notes that uses 2.18.0] — Reply to this email directly, view it on GitHub <#846 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANOGMFFLVMOPS65EUMZXT2K3R2TAVCNFSM6AAAAABROYIUGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJUGEYDONBQHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

aishanand · 2025-01-15T23:13:33Z

@cowtowncoder
2.18.2 is indeed used by spring 3.4 too !
here is the pom https://github.com/aishanand/personal/blob/main/pom.xml
dependency tree

cowtowncoder · 2025-01-16T06:26:28Z

Ah. I only saw the email notification and replied without reading the context.

As to fix, it is not clear behavior can or will be changed.

But instead of adding an empty constructor (which really shouldn't be needed) please considering adding annotation -- something I have mentioned multiple times in this thread:

@JsonCreator(mode = JsonCreator.Mode.DELEGATING)

on constructor. That will indicate that the incoming value should match the full argument value of 1-arg constructor, and not 1 property of JSON Object with name matching that argument.

I will also file an issue on jackson-databind to see if there is a way to create Java-only reproduction, and if so if the behavior could be changed.

cowtowncoder · 2025-02-08T04:04:59Z

Ok the issue I created on databind side does not seem to capture actual issue. Reading through comments here there may even be multiple different problem cases.

But fundamentally what would be needed would be Java translation of failing test case here, so I could see what is going on and perhaps how to resolve it.

One case I did notice tho was the case with no annotations: Jackson 2.18 can only auto-detect Mode.PROPERTIES constructors implicitly.

But Kotlin module could detect things differently, by KotlinAnnotationIntrospector.kt or KotlinNamesAnnotationIntrospector.kt implementing/overriding findDefaultCreator() -- that would then be used by databind as THE constructor to use.

It looks like this already exists, but I guess it won't detect case(s) here. WDYT @k163377 ?

k163377 · 2025-02-08T07:50:21Z

@cowtowncoder
I have submitted an Issue regarding a question I discovered during the translation process to Java.
Please check it.
FasterXML/jackson-databind#4960

baylrock added the bug label Nov 9, 2024

cowtowncoder mentioned this issue Jan 16, 2025

Consider selecting Mode.DELEGATING for Map-valued 1-arg constructors FasterXML/jackson-databind#4911

Closed

k163377 mentioned this issue Feb 8, 2025

If ImplicitPropertyName is present, one-argument constructors with JsonCreator.Mode.DEFAULT are treated differently than usual. FasterXML/jackson-databind#4960

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Missing empty constructor issue: deserialization breaking change from 2.17 to 2.18 #846

Missing empty constructor issue: deserialization breaking change from 2.17 to 2.18 #846

baylrock commented Nov 9, 2024 •

edited

Loading

cowtowncoder commented Nov 9, 2024 •

edited

Loading

fischl-viesure commented Nov 14, 2024

k163377 commented Nov 16, 2024

cowtowncoder commented Nov 17, 2024

cowtowncoder commented Nov 17, 2024 •

edited

Loading

baylrock commented Nov 17, 2024

cowtowncoder commented Nov 17, 2024 •

edited

Loading

fischl-viesure commented Nov 18, 2024

rafalh commented Jan 9, 2025 •

edited

Loading

cowtowncoder commented Jan 9, 2025

aishanand commented Jan 15, 2025 •

edited

Loading

cowtowncoder commented Jan 15, 2025 via email

aishanand commented Jan 15, 2025

cowtowncoder commented Jan 16, 2025

cowtowncoder commented Feb 8, 2025

k163377 commented Feb 8, 2025

Missing empty constructor issue: deserialization breaking change from 2.17 to 2.18 #846

Missing empty constructor issue: deserialization breaking change from 2.17 to 2.18 #846

Comments

baylrock commented Nov 9, 2024 • edited Loading

Search before asking

Describe the bug

To Reproduce

Expected behavior

Versions

Additional context

cowtowncoder commented Nov 9, 2024 • edited Loading

fischl-viesure commented Nov 14, 2024

k163377 commented Nov 16, 2024

cowtowncoder commented Nov 17, 2024

cowtowncoder commented Nov 17, 2024 • edited Loading

baylrock commented Nov 17, 2024

cowtowncoder commented Nov 17, 2024 • edited Loading

fischl-viesure commented Nov 18, 2024

rafalh commented Jan 9, 2025 • edited Loading

cowtowncoder commented Jan 9, 2025

aishanand commented Jan 15, 2025 • edited Loading

cowtowncoder commented Jan 15, 2025 via email

aishanand commented Jan 15, 2025

cowtowncoder commented Jan 16, 2025

cowtowncoder commented Feb 8, 2025

k163377 commented Feb 8, 2025

baylrock commented Nov 9, 2024 •

edited

Loading

cowtowncoder commented Nov 9, 2024 •

edited

Loading

cowtowncoder commented Nov 17, 2024 •

edited

Loading

cowtowncoder commented Nov 17, 2024 •

edited

Loading

rafalh commented Jan 9, 2025 •

edited

Loading

aishanand commented Jan 15, 2025 •

edited

Loading