Cannot use @JsonbCreator with absent fields

[emattheis]

In my experience, it is quite common to have JSON documents whose properties are present/absent depending on the scenario in which they are used. For example, the following two JSON documents might both represent a user:

{
  "firstName": "John",
  "lastName": "Doe"
}

{
  "firstName": "John",
  "middleInitial": "Q",
  "lastName": "Public"
}

I can easily map these documents to a Java class using the classic JavaBean pattern and JSON-B will be happy to deserialize either of the two documents above:

public class User {
    private String firstName;
    
    private String middleInitial;
    
    private String lastName;
    
    public String getFirstName() {
        return firstName;
    }
    
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    
    public String getMiddleInitial() {
        return middleInitial;
    }
    
    public void setMiddleInitial(String middleInitial) {
        this.middleInitial = middleInitial;
    }
    
    public String getLastName() {
        return lastName;
    }
    
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
}

However, if I want to map these documents to a Java class using an immutable pattern leveraging the @JsonbCreator annotation, it is disallowed by the spec:

import javax.json.bind.annotation.JsonbCreator;
import javax.json.bind.annotation.JsonbProperty;

public class User {
    private final String firstName;
    
    private final String middleInitial;
    
    private final String lastName;
    
    @JsonbCreator
    public User(@JsonbProperty("firstName") String firstName,
                @JsonbProperty("middleInitial") String middleInitial,
                @JsonbProperty("lastName") String lastName) {
        this.firstName = firstName;
        this.middleInitial = middleInitial;
        this.lastName = lastName;
    }
    
    public String getFirstName() {
        return firstName;
    }
    
    public String getMiddleInitial() {
        return middleInitial;
    }
    
    public String getLastName() {
        return lastName;
    }
}

Section 4.5 say:

In case a field required for a parameter mapping doesn’t exist in JSON document, JsonbException MUST be thrown.

In my opinion, usage of @JsonbCreator should be compatible with any document that can otherwise be deserialized by the default mapping methods, so this spec requirement is at odds with Section 3.14, which says:

The deserialization operation of a property absent in JSON document MUST not set the value of the field, the setter (if available) MUST not be called, and thus original value of the field MUST be preserved.

[rmannibucau]

+1 agree there is no reason it is not supported - didnt test but should work on johnzon impl by default too

[emattheis]

Sorry, I hit the 'Comment' button before I had finished my entire post 😛

@rmannibucau the problem is that the spec specifically disallows this support, so one cannot write portable code for this pattern.

I do this all the time with Jackson, but I'm interested in moving to the JSON-B spec for portability/consistency.

[rmannibucau]

Yep

Point being most impls support it and this is not backward incompatible - until you were using it to test some fields were absent but this was an antipattern already. So no issue to do it

[emattheis]

Sure, but how to address it in the spec? I'm using Resteasy which brings in Yasson which doesn't support this because it follows the spec precisely. Any implementation that allows this behavior is by definition not spec compliant.

[rmannibucau]

Do a pr to change the wording of the spec ;)

[emattheis]

I would if I knew where the spec source code was. Is there a repo for that somewhere?

Also, I'm curious to know how that clause made it in to the spec in the first place since it wasn't in the public draft I first reviewed. It seems that someone thought it was important and one can certainly imagine ways to preserve the existing behavior while allowing more flexibility.

e.g.

@JsonbCreator(treatAbsentAsNull = true)

[rmannibucau]

Hmm not sure where it is in new repo, it was in old one (https://github.com/javaee/jsonb-spec). Personally Id prefer to not have that toggle at all, it does not make sense and adds complexity for almost no gain at all.

[emattheis]

I agree with you, but I'm also not sure why the clause in section 3.14 exists. I would prefer to have the behavior for absent properties be the same for @JsonbCreator and the default deserialization methods, so null or Optional.empty() should be inferred for setters/field assignment as well. I think trying to retain an existing value after a deserialization is a mistake.

To set a default value in the event of an absent property, I would prefer to see the introduction of another annotation that does that explicitly.

e.g.

@JsonbDefaultValue("- valid JSON string here -")

In practice, there is no good way to distinguish between an explicitly null property and a missing property once the JSON has been deserialized.

[rmannibucau]

If needed it can be done in the constructor, if forbidden the constructor validates it anyway (potentially with business value) so at the end there is not a single valid case not enabled and it would align constructor on setters/fields behavior which is way saner IMHO.

[emattheis]

Not sure I follow. As it stands today, if you have the following JSON:

{}

and you deserialize to the following class:

public class Value {
    private String value = "DEFAULT";
    
    public String getValue() {
        return value;
    }
    
    public void setValue(String value) {
        this.value = value;
    }
}

then getValue() should return "DEFAULT".

On the other hand, if you use this class:

import javax.json.bind.annotation.JsonbCreator;
import javax.json.bind.annotation.JsonbProperty;

public class Value {
    private final String value;
    
    @JsonbCreator
    public Value(@JsonbProperty("value") String value) {
        this.value = value;
    }
    
    public String getValue() {
        return value;
    }
}

then it MUST fail per the spec, but you're saying that johnzon works, in which case getValue() should return null, so the behavior is fundamentally different from the other class.

Trying to write a default in the setter or constructor doesn't work because your code cannot tell if there was an explicit null in the payload or if the property was absent (and, of course, it wouldn't work if you wanted to use field assignment directly for some reason).

That being said, I don't have any compelling reason to WANT a default value, but it seems like someone must given the language in the spec. I'd be happy to see it changed to state that null or Optional.empty() will be inferred for any mapped property missing from the JSON document.

[rmannibucau]

The point is that default or error cases must be handled in an user method anyway so only feature failing is parsing error which is not very valuable here since trivially replaced by error case. Doing the change dont break apps, so null is fine in all cases IMHO.

[bravehorsie]

@emattheis
@JsonbCreator(treatAbsentAsNull = true) would prevent errors when property is missing in JSON unintentionally and is actually required. If set to true a constructor could further check a property for null to set the default value.

That being said, I don't have any compelling reason to WANT a default value, but it seems like someone must given the language in the spec. I'd be happy to see it changed to state that null or Optional.empty() will be inferred for any mapped property missing from the JSON document.

In order to set null for all missing properties implementation would have to post process every object after deserialization, because it would not be "called" explicitly to set a property with null when the property doesn't appear in the JSON document. Post processing would further slow down the performance.

[rmannibucau]

It depends a lot the impl and perf will not vary for most of them thanks to the buffering.

[emattheis]

The point is that default or error cases must be handled in an user method anyway so only feature failing is parsing error which is not very valuable here since trivially replaced by error case. Doing the change dont break apps, so null is fine in all cases IMHO.

@rmannibucau I agree, but I still think it's better for @JsonbCreator to behave the same way as setter/field access with respect to absent properties. I think section 3.14.1 is problematic because it describes asymmetrical behavior with regard to serialization and deserialization - i.e. null values result in absent properties when serializing, but absent properties will not necessarily result in null values when deserializing. Also, on a slightly related topic, the spec doesn't seem to mention how null values should be handled in a map.

In order to set null for all missing properties implementation would have to post process every object after deserialization, because it would not be "called" explicitly to set a property with null when the property doesn't appear in the JSON document. Post processing would further slow down the performance.

@bravehorsie couldn't the builder object responsible for constructing a type be pre-initialized with defaults for mapped properties? Then those values would naturally be present for anything the parser didn't explicitly fill in. I haven't dug that far into the Yasson code, but it seems doable with minimal overhead from a design perspective.

[emattheis]

@bravehorsie after looking into the Yasson codebase, I see what you mean. Still, it looks trivial to support null for absent properties in the creator case.

I think I'm coming around to @rmannibucau's point of view: relaxing the spec and supporting null for absent properties in creators should be very low impact - at worst you get a null value in a field where you used to get a complete failure to parse. The spec can point out the pitfalls of this behavior in contrast to the default behavior. If someone wants to mix and match creator and property/field access, they can still do so and retain the default behavior for certain fields. Those looking to leverage creators for immutable types will get what they expect.

I'll put together a PR for Yasson and I'm happy to submit a PR for the spec as well if there's a repo for that.