Skip to main content

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Sample code using the jsr353 api

  • From: Jörn Horstmann < >
  • To:
  • Subject: [json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Sample code using the jsr353 api
  • Date: Fri, 07 Dec 2012 23:17:36 +0100
  • List-id: <jsr353-experts.json-processing-spec.java.net>

On 12/06/2012 08:55 PM, Jitendra Kotamraju wrote:
Problem with having individual types, roundtripping doesn't work at all
(JsonArray --> JSON text --> JsonArray)

JsonArray a1 = new
JsonBuilder().startArray().add((long)100).end().build(); // JsonNumber
value type is long

JsonArray a2 = new JsonReader("[100]") // JsonNumber value type is int

a1 is not equal to a2. With BigDecimal i.e (int, long, BigInteger,
double, BigDecimal, String --> BigDecimal), it works out well.

Yes, equality is a difficult problem. Even when sticking to BigDecimal "1.0" won't be `equal` to "1.00", due to different scales.

When building json structure the number could be automatically converted to the smallest possible type, so `add((long)100)` would in fact create a JsonNumber of type INT. The same could be done when adding a BigDecimal with a scale of 0 which is in the range of the int or long type. I'm not a fan of all this additional rangechecking code, but what do you think?

I suggested before to remove the distinction between INT and LONG in NumberType, and instead only differentiate whether the number contains a fractional part. I think this would simplify the required logic, without any downsided. User code or a binding api would know beforehand whether a int or long is required and call the appropriate methods. I don't think there is any performance of space benefit of first checking the number type for int or long. If users code needs this distinction it could call getLongValue and do the rangecheck itself.

On SE/EE, if converting String, int,long, double, BigInteger, BigDecimal
-> BigDecimal behind the scenes and using it for all the semantics, then
I am good with that approach.


I think the getIntValue and getDoubleValue methods should be kept in
any case for convenience.
I think so, but those can be delegated to Number.

Jitu

As JsonNumber is an interface there could be optimized implementations, for example just wrapping an int field. Having these methods directly on JsonNumber would allow to get this value without creating any temporary objects.

Jörn


[json-processing-spec users] [jsr353-experts] Re: Re: Re: Sample code using the jsr353 api

(continued)

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Sample code using the jsr353 api

Werner Keil 12/05/2012

Message not available

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Sample code using the jsr353 api

Jörn Horstmann 12/05/2012

[json-processing-spec users] Re: [jsr353-experts] Re: Re: Re: Sample code using the jsr353 api

Jitendra Kotamraju 12/06/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Sample code using the jsr353 api

Jörn Horstmann 12/06/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Sample code using the jsr353 api

Werner Keil 12/06/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Sample code using the jsr353 api

Jitendra Kotamraju 12/07/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Sample code using the jsr353 api

Werner Keil 12/07/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Sample code using the jsr353 api

Jitendra Kotamraju 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Sample code using the jsr353 api

Werner Keil 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Sample code using the jsr353 api

Jitendra Kotamraju 12/06/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Sample code using the jsr353 api

Jörn Horstmann 12/07/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Jitendra Kotamraju 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Jörn Horstmann 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Werner Keil 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Jitendra Kotamraju 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Werner Keil 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Jitendra Kotamraju 12/11/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Werner Keil 12/11/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Jörn Horstmann 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Werner Keil 12/09/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Re: Re: Re: Re: Sample code using the jsr353 api

Jitendra Kotamraju 12/09/2012
 
 
Close
loading
Please Confirm
Close