Deserialization in Yasson 3 is no more strict.

[thomas-fra]

Describe the bug
Deserialization in Yasson 3 is no more strict.
If I have a class with a long value and on the json, there is a double value, where deserializing the content, there is no more exception and the double value is truncated into the long variable.

To Reproduce

public class MyClass {
private Long lid;
}

    JsonbConfig config = new JsonbConfig().withFormatting(true).withStrictIJSON(true);
    Jsonb jsonb = JsonbBuilder.create(config);
    String json= "{ lid\":1254.5 }";
    myInstance = jsonb.fromJson(json, MyClass.class);
    Assert.fail("1254.5 Should not be allowed on lid - Long attribute");

Expected behavior
Having a JsonbException thrown

System information:

• OS: Windows
• Java Version: 17
• Yasson Version: 3.0.4

Additional context
Happened when migrating from wilffly 26.1.3 to wildfly 35.0.1

[KyleAure]

@thomas-fra @arimu1

Thank you Thomas for opening issue and Arimu for providing a fix.

When reading through the Strict I-JSON section of the Jakarta JSON B specification and RFC7493 the information about number handling is mostly related to how we serialize numbers into JSON to ensure we meet the I-JSON format.
Therefore, I do not believe I-JSON has any bearing as to how we deserialize numbers to Java Number types, and so I do not agree that we currently fail to comply with the Strict I-JSON support.

That being said, I do recognize that a behavior change was introduced between 2.0 and 3.0.
Namely, that we now attempt to coerce numbers from JSON fields into the appropriate Java Number type during deserialization.
When I reference the specification the language in Section 3.3.2 says:

[Deserialization] ... MUST follow the conversion process defined in the javadoc specification for the corresponding parse$Type method

IMO that is pretty clear that parsing a JSON Number with a fractional component should throw an error during deserialization when targeting an Integer or Long field, and that such behavior should not be limited to I-JSON enabled Jsonb instances.

Do you agree @jamezp?
This will be a behavior change between 3.0 and 3.1, however, from the feedback I've gotten from the community recently have swayed me more towards being more strict than less strict. A similar issue was brought to my attention where we allow parsing {"a": "true"} to a boolean field even though the JSON was a STRING value and not a TRUE/FALSE value.
We could also look at defining our own strict mode for deserialization that won't try to coerce values where users might not expect it.

[jamezp]

@KyleAure I agree with you and it makes sense to me to be more strict here.