MissingKotlinParameterException: due to missing (therefore NULL) value for creator parameter … which is a non-nullable type

[steffenkolb]

We ran into the following issue when we tried to deserialize a JSON string coming from our Spring rest controller.

 FATAL EXCEPTION: main
    Process: com.example.driver, PID: 28305
    java.lang.IllegalStateException: Failed to load DataModel: com.fasterxml.jackson.module.kotlin.MissingKotlinParameterException: Instantiation of [simple type, class com.example.model.StorageDevice] value failed for JSON property storageDeviceId due to missing (therefore NULL) value for creator parameter storageDeviceId which is a non-nullable type
        at [Source: (okhttp3.ResponseBody$BomAwareReader); line: 1, column: 1764] (through reference chain: com.example.model.DataModel["storageDevices"]->java.util.ArrayList[0]->com.example.model.cargospace.StorageDevice["storageDeviceId"])
        at com.example.model.RestTourRepository$updateDataModel$1.onFailure(RestTourRepository.kt:38)
        at retrofit2.ExecutorCallAdapterFactory$ExecutorCallbackCall$1$2.run(ExecutorCallAdapterFactory.java:79)
        at android.os.Handler.handleCallback(Handler.java:751)
        at android.os.Handler.dispatchMessage(Handler.java:95)
        at android.os.Looper.loop(Looper.java:154)
        at android.app.ActivityThread.main(ActivityThread.java:6121)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:889)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:779)

The object we try to construct looks like this:

@JsonIdentityInfo(
        generator = ObjectIdGenerators.PropertyGenerator::class,
        property = "storageDeviceId"
)
data class StorageDevice (
    val storageDeviceId: String,
    val configuration: AbstractStorageDeviceConfiguration,
    val storageDeviceLocation: StorageDeviceLocation
)

And the JSON string we receive is the following:

{
    "storageDeviceId": "71ba49f3-d8c8-425f-b7e4-29b8c49f417d",
    "id": 166,
    "configuration": {
        "storageDeviceConfigurationId": "c2c926b3-de70-491a-9f8d-514830d56a4b",
         …
    },
    "storageDeviceLocation": "1f64613b-6e96-4825-a489-faa00608516e",
    "new": false
}, …

We solved the issue by changing the val storageDeviceId: String to val storageDeviceId: String?. The value was then properly set after deserialization.

The question arises why we had to set it to nullable in the first place?

Versions:
jackson-module-kotlin:2.9.0
jackson-annotations:2.9.0

[zdevwu]

I'm having a similar problem with Map<k,v> type. The exception will be thrown when the map property doesn't exist in the json string.

For deserilization In kotlin, probably it is reasonable to have an default value assigned to none-nullable types as the none-nullable types are encouraged at the kotlin language level. It should be acceptable.

A set of defaults in my opinion:

String: ""
Map<k,v>: emptyMap()
MutableMap<k,v>: mutableMapOf()
Number: 0
...

[asarkar]

Same here. This is a bug; if the property has a default value, Jackson should use that and not treat it as null. An empty collection is not null.

[apatrida]

@zdevwu you can set default values in your constructor or property setting, and the module will see it and let it be set without complaint.

@asarkar do you have a specific case that is failing where you set a default value and it is ignored? Or are you wanting implicit defaults (implicit defaults are not going to happen, that would not allow for missing value checking)

[asarkar]

@apatrida It’s been a month so I don’t remember the use case clearly, and I’m not sure what you mean by implicit defaults. The behavior I think I saw was when the data class was created without setting a value for the collection with the default value, Jackson complained during serialization that the value was null for a non-nullable type

[zdevwu]

@apatrida if it is the kotlin module, it needs to be done the kotlin way. Nullable type should not be forced to use to solve the problem here. You can argue using default value explicitly can solve my problem but it would be much nicer the kotlin module can do it for us, as there are default convention values like "", emptyMap() that one would usually use when declaring a member variable. So we can type less characters and be more productive

[yusufaytas]

agree with @zdevwu. Experiencing the same issue without a real solution.

[manikantagarikipati]

Facing the same issue here. Is there any workaround to make kotlin module make the default values stay intact when the json rest response is having null for particular fields???

[asarkar]

@apatrida this issue is open for several months, and more than one person has reported it. Is there something else we need to do to get your attention and get it fixed?

[cowtowncoder]

@asarkar Please do note that this is a fully volunteer-based open source project. We all have our lives, and participation here has to compete with many other things which generally are more important (family for example). So although I trust you did not mean your comment to sound like it, it came across bit strong as if there was some entitlement to quick service, solely based on the fact that you would like to see it fixed. There is no service expectation, and asking for status updates is typically not very helpful in getting things to move.

[asarkar]

Of course there are no service guarantees, let alone entitlements. However, what is lacking here is the acknowledgement that the reported issue is a bug, and will be addressed in a future release. “this is open source” argument is too much of a cliche, isn’t it? I work with and contribute to open sources myself, and one thing I often see is a strong resistance and/or obliviousness to problem reports, and putting the onus squarely on the reporter as if it’s their fault having found an issue with the code.

[cowtowncoder]

@asarkar And yet you are asking for specific actions, trying to read motivations into lack of updates, most easily explained by lack of time to spend.

As to "this is open source"... It is literally something maintainers do for free, and has to compete with other priorities. As you probably know well given your work in field of OSS.

[cowtowncoder]

@manikantagarikipati Jackson 2.9 does have @JsonSetter annotation that does allow skipping of nulls:

https://medium.com/@cowtowncoder/jackson-2-9-features-b2a19029e9ff

which works well when used on setters, or fields serving as setters. I am not sure if that might work for your usage.

[araqnid]

I'd be strongly against Jackson inventing defaults for properties and covering up for them being missing in the input. If a property defaults to emptyMap() when not specified, a constructor parameter default is a precise way of specifying that, no magic "implicit defaults" needed or desired.

[araqnid]

Also, the question of putting implicit defaults on non-nullable properties seems to be quite different from the original bug report, which implied that an identity property was being set after object creation rather than being applied to the creator function.

[mykolapolonskyi]

If this issue appears with Spring Controllers(or another controllers)
its semantically correct to setup ControllerAdvice for this issue with 400 status and representative error message, when DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES is on in configuration(maybe other options should be included)

Because - when jackson got field:null and try to set it - its correct (default value should be used when value is absent - it event called default =) )

So when request try to put null to not null its bad request

So the point - is it bug or missconfiguration/missunderstanding?