Thanks Jonathan, thats a nice summary of the issues regarding JsonNumber.We had that discussion. For e.g http://java.net/projects/json-processing-spec/lists/users/archive/2012-10/message/48
Also for other languages that include a more complete numeric tower. I haven't come across an example where numeric strings are used to preserve precision, this might be fine if the value is just used for display purposes in a browser, but for a data exchange format the number syntax should be preferred.
As api or library providers we should try to keep the most precision possible for a number and let the library user decide how it is treated. This can be done by either storing the number as a BigDecimal or String internally. If we allow both storage options the contract for equals and hashCode would have to be based on
their string representation, as the hashCode calculation for BigDecimal is not exactly specified.If we don't define equals and hashCode, then objects from provider 1 will not work with objects of provider 2. I don't know if that's a problem for anybody.
(Consistent equals and hashCode behaviour is the main reason that I would prefer JsonBuilder and related classes to be interfaces, so an implementation could use the same classes for numbers created from builder and reader usage.)
I hope that most java developers dealing with monetary values are using BigDecimal, and so should be familiar with its behavior of equals. I also think that equal checks are mostly done between objects from the same source.
And finally I think a specification can also intentially leave things undefined or implementation defined when it allows performance or space advantages.
So in pseudocode, ~ meaning equals, build being a shortcut for JsonBuilder and parse for JsonReader:
equals returns true:
parse("10.0") ~ parse("10.0")
build(10.0) ~ build(10.0)
build(new BigDecimal("10.0")) ~ build(new BigDecimal("10.0"))
equals returns false
parse("10.0") ~ parse("10")
build(new BigDecimal("10.0")) ~ build(new BigDecimal("10"))
implementation defined return value
parse("10.0") ~ build(10.0)
build(10.0) ~ build((int)10)
build(new BigDecimal("10.0")) ~ build(10.0)
This might be controversial at first but its alway possible to tighten the rules in a maintenance release, while its not possible to loosen the definitions due to backwards compatibility.
[json-processing-spec users] Re: BigDecimal for equals()/hashCode()