Proposed change of default serialization datatype of BigInteger
11 views
Skip to first unread message
Richard Wise
Oct 31, 2019, 12:21:05 PM10/31/19
to jackson-dev
Hello,
Long-time user and fan of Jackson here. I find the library extremely useful and reliable and generally have no issues with it. However, I would like to propose a a change in approach for how Java BigIntegers are serialized. Currently, by default, they are serialized to JSON Numbers with the option to serialize them as a String if required. I propose that this approach is switched, such that the default datatype is a JSON String.
The reason for this proposal is that JSON Number has an implementation-specific precision limit, whereas BigInteger does not. This means that there are edge cases where the round trip serialisation + deserialisation does not match.
In addition, the only accurate way to construct a BigInteger in Java is with the String constructor, so the symmetry between JSON deserialisation and construction is missing.
When I proposed this in https://github.com/FasterXML/jackson-databind/issues/2517, the two main disagreements were that numbers should remain as numbers and that it would be hard to break the API.
To address the API break first - I completely agree. A non-backwards compatible approach change such as this is always expensive, but I'm sure you'll agree that it is worth doing to improve the library for the future. Personally, I am more than happy to triage any related bugs and write documentation to explain the rationale for changing.
Secondly, I completely agree with the statement that numbers should remain as numbers. However, BigInteger is not just a number - it is an arbitrary precision number. Given there is no datatype that supports arbitrary-precision numbers in JSON, I would say that the choice is between storing as a number (and risking precision truncation) or storing as a string (non-intuitive). Given that most use cases for BigInteger will be scenarios where a normal long or int will not suffice, I would argue that losing precision is likely and is very hard to debug and test.
Therefore, I think that it is better for users to face the confusion of their BigInteger always serializing as a string compared to the confusion of their BigInteger losing precision in certain scenarios.
Thoughts?
Long-time user and fan of Jackson here. I find the library extremely useful and reliable and generally have no issues with it. However, I would like to propose a a change in approach for how Java BigIntegers are serialized. Currently, by default, they are serialized to JSON Numbers with the option to serialize them as a String if required. I propose that this approach is switched, such that the default datatype is a JSON String.
The reason for this proposal is that JSON Number has an implementation-specific precision limit, whereas BigInteger does not. This means that there are edge cases where the round trip serialisation + deserialisation does not match.
In addition, the only accurate way to construct a BigInteger in Java is with the String constructor, so the symmetry between JSON deserialisation and construction is missing.
When I proposed this in https://github.com/FasterXML/jackson-databind/issues/2517, the two main disagreements were that numbers should remain as numbers and that it would be hard to break the API.
To address the API break first - I completely agree. A non-backwards compatible approach change such as this is always expensive, but I'm sure you'll agree that it is worth doing to improve the library for the future. Personally, I am more than happy to triage any related bugs and write documentation to explain the rationale for changing.
Secondly, I completely agree with the statement that numbers should remain as numbers. However, BigInteger is not just a number - it is an arbitrary precision number. Given there is no datatype that supports arbitrary-precision numbers in JSON, I would say that the choice is between storing as a number (and risking precision truncation) or storing as a string (non-intuitive). Given that most use cases for BigInteger will be scenarios where a normal long or int will not suffice, I would argue that losing precision is likely and is very hard to debug and test.
Therefore, I think that it is better for users to face the confusion of their BigInteger always serializing as a string compared to the confusion of their BigInteger losing precision in certain scenarios.
Thoughts?
Tatu Saloranta
Nov 1, 2019, 2:39:08 PM11/1/19
to jacks...@googlegroups.com
one ground rule that I should mention.
Due to significant compatibility change, default change, if one is to
be done, would be for 2.x -> 3.0 major version change. But not for
2.x.
There are a few other setting changes that are being contemplated (or
even implemented),documented here:
https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-2
-+ Tatu +-
Reply all
Reply to author
Forward
0 new messages