Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NonNull Types for Map values can contain null values #392

Closed
Legion2 opened this issue Nov 1, 2020 · 1 comment
Closed

NonNull Types for Map values can contain null values #392

Legion2 opened this issue Nov 1, 2020 · 1 comment
Labels

Comments

@Legion2
Copy link

Legion2 commented Nov 1, 2020

Describe the bug
When deserializing an object into a map of a NonNull value Type, e.g. Map<String, String> there should be no null values in the map. But no exception is thrown when deserializing an object which contains null values into such a map, which then contains null values and cause NPEs.

To Reproduce
Following test demonstrates the bug:

    @Test
    fun test() {
        val objectMapper = ObjectMapper()
        objectMapper.registerKotlinModule()
        assertThrows<RuntimeException> {
            objectMapper.readValue<Map<String, String>>("""
            {
                "key1": "value",
                "key2": null
            }
            """.trimIndent())
        }
    }

Expected behavior
When the value type of a map declares to be non nullable there should be no null values at runtime, otherwise it breaks kotlin's Null Safety. Instead an error should be reported when there is a null value.

Versions
Kotlin: 1.3.72
Jackson-module-kotlin: 2.11.3
Jackson-databind: 2.11.3

@Legion2 Legion2 added the bug label Nov 1, 2020
@k163377
Copy link
Contributor

k163377 commented Mar 3, 2023

Basically, this can only be prevented by enabling the StrictNullChecks option (note that enabling this option currently has a significant performance penalty).
Also, for readValue<Map<String, String>>, no null checks are performed even if the StrictNullChecks option is enabled, because of the problem in and #399.

This issue is closed as a duplicate of #399.

@k163377 k163377 closed this as completed Mar 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants