Illegal JSON: Long limitation vs ECMA limitation

[enexusde]

Return a complex JSON having a long-value of -1369082024195183657 resolves in illegal JSON.

{ id:20,
  data:{
    name: 'max',
    age: 21,
    hash: -1369082024195183657 
  }
}

But in browser data.hash Resolves to -1369082024195183600

A solution could be  
{ id:20,
  data:{
    name: 'max',
    age: 21,
    hash: -1369082024195183600 + 57 
  }
}

At least the JSON is correct, the client must parse and throw an error if the client has no support for big integers then.

[cowtowncoder]

I am not sure I understand what your problem here is. What is Jackson doing, and why is that problematic? Jackson accepts numbers of unlimited length at parser level; the only limits are imposed when binding it to datatypes, as per limits of specific datatypes.

[enexusde]

Jackson is returns illegal JSON. What exactly is your question?

[cowtowncoder]

@enexusde I do not see any example of what, how or where: Jackson would never -- for example -- leave out double-quotes; nor does JSON enforce any limits on magnitude or precision of floating point or integral numbers. In addition term "illegal" is not something used with data formats; perhaps you mean "invalid" or "non-well-formed". Nonetheless it is necessary to point out how exactly would output be against JSON specification.

As to client-specified limitations (like Javascript's inability to support 64-bit integers, for example), those are different kettle of fish.

[enexusde]

I grant that the spec of the IETF rfc7159 and ECMA404 differs, but the IETF is more widely used than the ECMA Cons. Invalid and Illegal comes from validation and legalization, in my eyes something can be valid but not legal, in example there is nothing like a -0 so its valid but not legal because 0 is neutral.

I respectfully disagree in "nor does JSON enforce any limits on magnitude or precision of floating point or integral numbers", i would say "nor does ECMA enforce any limits on magnitude or precision of floating point or integral numbers".

I insist on -1369082024195183657 is not a legal(nor valid) value in json because of the limitation of the ietf.

[cowtowncoder]

@enexusde I do not see any such limitations within RFC 7159 either; I also consider RFCs more definitive than ECMA standard(s) in this context. As to numeric representations: these issues were extensively (but to large degree fruitlessly) discussed on json spec mailing list, and my reading was that original JSON specification reading stands: there are no limits by the format itself. Implementations may choose to limit range of valid textual representations that they can work with (like javascript's inability to use internal representation are than 64-bit double precision). As such I don't quite see the point for Jackson to limit precision or range, given that Java has simple facilities to support big integers (BigInteger) and floating-point numbers (BigDecimal).

But I still do not understand what exactly would be asked, assuming limitations were defined in the specification. I would understand request to add a JsonParser.Feature or JsonGenerator.Feature to add further constraints to either error or perhaps truncate values. What I don't understand is general categorical claim of a violation and explaining what part of behavior should change, and why. Why part is important since there are many endpoint configurations where full numeric range is available: obvious one being Java client connecting to Java service; but many/most other platforms are also able to use full numeric ranges. Jackson, on the other hand, has no knowledge of possible limitations of other endpoints; and using lowest-common denominator seems like a really bad idea -- one could not, for example, use standard Java 64-bit long timestamp notation for date/time values.

[cowtowncoder]

Nothing to fix here: long numeric values are valid JSON, even if something that Javascript clients can not represent.