Allow @JsonCreator annotated Creator to retun null

[f-aubert]

Is your feature request related to a problem? Please describe.

When using JsonCreator on a factory (static) method, we have the possibility of returning null (because for example all the arguments are empty). However during deserialization an exception is thrown, java.lang.NullPointerException: JSON Creator returned nul.

I think it would make sense to allow deserialization to null

Describe the solution you'd like

Improve the code robustness in the BeanEntityDeserializer to allow Deserialization to null if a static JsonCreator explicitly allows it.

Usage example

@JsonCreator
public static Localized3 of(@JsonProperty("en") String en, @JsonProperty("de") String de, @JsonProperty("fr") String fr) {
        if (en == null && de == null && fr == null) {
            return null;
        }

        return new Localized3(en, de, fr);
}

should be allowed for Deserialization and { en: null, de: null, fr: null } should deserialize to null

Additional context

No response

[JooHyukKim]

Seems like reasonable request, but this request conflicts with current behavior.
According to #597, users might be actually building things on top of current behavior.

So either of ....

1. Intentionally change current behavior
2. introduce a new configuration f.ex DeserializationFeature.ALLOW_NULL_RETURNING_CREATOR
3. TBD

[JooHyukKim]

Here is reproduction

public class JsonCreatoreReturningNull4938Test
    extends DatabindTestUtil
{
    // The class with the JsonCreator static factory method
    static class Localized3 {
        public final String en;
        public final String de;
        public final String fr;

        @JsonCreator
        public static Localized3 of(
                @JsonProperty("en") String en,
                @JsonProperty("de") String de,
                @JsonProperty("fr") String fr) {
            if (en == null && de == null && fr == null) {
                return null; // Explicitly return null when all arguments are null
            }
            return new Localized3(en, de, fr);
        }

        private Localized3(String en, String de, String fr) {
            this.en = en;
            this.de = de;
            this.fr = fr;
        }
    }

    private final ObjectMapper MAPPER = newJsonMapper();

    @Test
    void testDeserializeToNullWhenAllPropertiesAreNull() throws Exception {
        // JSON input where all properties are null
        String json = "{ \"en\": null, \"de\": null, \"fr\": null }";

        // Deserialize JSON to Localized3 object
        Localized3 result = MAPPER.readValue(json, Localized3.class);

        // Verify that the result is null
        assertNull(result, "Deserialization should result in null when all properties are null");
    }

}

[f-aubert]

@JooHyukKim thanks for considering my request and adding the missing test case! That's very nice. I also read the referred issue 597 but no one there seems to demonstrate a usage of the current behavior and I could not think of one either. My guess would be a better exception helped debugging code or simply throwing better error message. But a DeserializationFeat would also work. But you seems to limit them?

[JooHyukKim]

@cowtowncoder WDYT?

[cowtowncoder]

What is the current exception? To me, ability to return null seems reasonable and I am not sure why it should be considered error case. I don't remember past reasoning.

If we do want it to be optional, DeserializationFeature seems reasonable.

[cowtowncoder]

Oh. I think I may remember why null was blocked: for Properties-based case there's now nothing to bind possible extra properties to -- so code was being bit opinionated.

However, I think in that case we should just skip following properties and take null to mean nothing more is to be used from that level. At least that seems reasonable enough to me now.

So I think I'm ok actually changing behavior for 2.19, without configurability.

That is, unless someone can come up with a scenario where this should be prevented (configurably or not).

[cowtowncoder]

So just make sure: I am +1 for allowing this, and working with @JooHyukKim on a pr to get implemented for 2.19.