Jackson JSON Processor
  1. Jackson JSON Processor
  2. JACKSON-617

Add config to deserialize from JSON null value to default primitive value for field of wrapper type

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      When a JSON null value is deserialized to a primitive int field, the int field is populated with its default value of 0. (I did not check, but I wouldn't be surprised if similar handling is provided when deserializing to other primitive types.)

      However, currently when a JSON null value is deserialized to a field of one of the primitive wrapper types, e.g., Integer, then the field is set to null, i.e., it's deserialized as a null reference.

      Jackson should provide a deserialization configuration feature to allow the user to specify that the default primitive value is preferred, instead of a null reference. This deserialization feature should operate similarly when deserializing from an empty JSON string.

      Brainstorming for a name for this deserialization config feature:

      DeserializationConfig.Feature.USE_PRIMITIVE_DEFAULTS_FOR_WRAPPER_NULLS
      DeserializationConfig.Feature.USE_PRIMITIVE_DEFAULTS_FOR_EMPTY_WRAPPERS
      DeserializationConfig.Feature.PRIMITIVE_DEFAULT_FOR_EMPTY_WRAPPER
      DeserializationConfig.Feature.CONVERT_NULL_TO_PRIMITIVE_DEFAULT
      DeserializationConfig.Feature.CONVERT_EMPTY_TO_PRIMITIVE_DEFAULT

        Activity

        Hide
        Tatu Saloranta added a comment -

        Ok. Yes, need to come up with name for this feature.

        Show
        Tatu Saloranta added a comment - Ok. Yes, need to come up with name for this feature.
        Hide
        Tatu Saloranta added a comment -

        I guess that there is also question of how to combine this with empty String handling.
        I assume that conceptually it would make sense to first consider empty Strings as nulls; and then, if this feature is enabled, further coerce into default value for wrappers (if disabled, set as null).
        Does this make sense?

        Show
        Tatu Saloranta added a comment - I guess that there is also question of how to combine this with empty String handling. I assume that conceptually it would make sense to first consider empty Strings as nulls; and then, if this feature is enabled, further coerce into default value for wrappers (if disabled, set as null). Does this make sense?
        Hide
        Programmer Bruce added a comment -

        Yes.

        This deserialization feature should operate similarly when deserializing from an empty JSON string.

        Show
        Programmer Bruce added a comment - Yes. This deserialization feature should operate similarly when deserializing from an empty JSON string.
        Hide
        Antony Stubbs added a comment -

        Support for allowing custom deserialisers to define behavior for deserialsing nulls would be great too.

        Show
        Antony Stubbs added a comment - Support for allowing custom deserialisers to define behavior for deserialsing nulls would be great too.
        Hide
        Antony Stubbs added a comment -

        Cough, JsonDeserializer#getNullValue, cough...

        Show
        Antony Stubbs added a comment - Cough, JsonDeserializer#getNullValue, cough...
        Hide
        Tatu Saloranta added a comment -

        Yes.

        Show
        Tatu Saloranta added a comment - Yes.
        Hide
        Tatu Saloranta added a comment -

        Will close for now, only because we are moving issues to github.
        So if you still want feature(s) to be implemented, please re-file at:

        https://github.com/FasterXML/jackson-databind/issues

        That is, closing does not mean "will not even consider implementing", but rather "if it still wanted, please re-create at the new issue tracker".
        Just part of kind of autumn cleanup of open issues.

        Show
        Tatu Saloranta added a comment - Will close for now, only because we are moving issues to github. So if you still want feature(s) to be implemented, please re-file at: https://github.com/FasterXML/jackson-databind/issues That is, closing does not mean "will not even consider implementing", but rather "if it still wanted, please re-create at the new issue tracker". Just part of kind of autumn cleanup of open issues.

          People

          • Assignee:
            Tatu Saloranta
            Reporter:
            Programmer Bruce
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: