Open aguibert opened 4 years ago
Hi
+1 to just drop it
IEEE 754 double precision check is not easy to implement. I have my own experience from yasson :) On the other hand it's nice to support it and produce smaller Number type than BigDecimal that can hold the value.
But I agree that there is no reason to have such a requirement in the specification.
Also I would like to correct few more things there.
Serialization of java.lang.Number instances (if their more concrete type is not defined elsewhere in this chapter) to a JSON string MUST retrieve double value from ... ... Deserialization of a JSON value into java.lang.Numbertype MUST return an instance of java.math.BigDecimal by using conversion process defined in the javadoc specification for constructor of java.math.BigDecimal with java.lang.String argument.
JSON string
to JSON number
in this section. This sounds like Java Number instance shall be serialized as RFC 8259 JSON String value.Seems this issue got silently "resolved" by forcing JSON Number for BigX types but JSON-B explicitly states to break JSON parser, don't think it is great so BigX should always be mapped to string rather than numbers. Ultimately I guess jsonbconfig should get a toggle for that instead of trying to be more clever than we can.
ultimately BigXXX (BigDecimal at least) support could also be deprecated as being built in since it has some very serious impact when exposed publicly (rest for ex) and replaced by an adapter to enable offline cases? (thinking out loud there)
Currently section 3.16 of the JSON-B 1.0 spec states:
After receiving some user feedback, implementations decided that this is not ideal behavior and the TCK test was challenged and excluded here: https://github.com/eclipse-ee4j/jsonb-api/issues/180
Yasson has removed this behavior here: https://github.com/eclipse-ee4j/yasson/issues/269
My current stance is that we should simply remove section 3.16 from the spec, but at minimum this section should change in some way.