jakartaee / jsonb-api

Jakarta JSON Binding
https://eclipse-ee4j.github.io/jsonb-api/
Other
78 stars 39 forks source link

Revise BigNumber support #187

Open aguibert opened 4 years ago

aguibert commented 4 years ago

Currently section 3.16 of the JSON-B 1.0 spec states:

3.16 Big numbers

JSON Binding implementation MUST serialize/deserialize numbers that express greater magnitude or precision than an IEEE 754 double precision number as strings.

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.

rmannibucau commented 4 years ago

Hi

+1 to just drop it

Tomas-Kraus commented 4 years ago

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.

3.3.4 java.lang.Number

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.

  1. I would like to change JSON string to JSON number in this section. This sounds like Java Number instance shall be serialized as RFC 8259 JSON String value.
  2. Why deserialization of a JSON value into Java Number shall always produce BigDecimal?
rmannibucau commented 1 year ago

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)