On Thu, Oct 31, 2019 at 9:21 AM 'Richard Wise' via jackson-dev <[email protected]> wrote: > > 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?
I think I should let others share their thoughts here, but there is 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 +- -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10iq7YDv-MsWGYHku_0YsayHVoUgs%3D8KbZvf8EDy7bOqDA%40mail.gmail.com.
