3

I am using Java 16 and spring-boot (2.5.3) to create a REST api which returns a Long property and also the String version of the Long property. The Long is created via Javas Random().nextLong() and the String via toString() of that Long value. In the return object I set the Long to prop1 and the String to prop2. If I debug my code both values inside the return object are the same. If I look at my response inside the browsers devtools both sometimes are different.

Example: prop2: "8809294616433182964", prop1: 8809294616433183000

Can someone explain the reason for this and how to use a Long without this happening? If I use Long.valueOf(Random().nextInt()) everything works fine, so it somehow dependents on the size of the long value.

All my objects ids are Long based and I don't want to have a problem with this if the ids get too big.

chaosKP
  • 41
  • 3
  • If everything is setup as you described, then both values should be the same. Could you please share Your code (a minimal reproducing example, at best)? Did you try to set `Long.MAX_VALUE`? What does Your response look like in that case? – slartidan Aug 18 '21 at 09:51
  • 1
    JavaScript does not support 64-bit integers out-of-the-box, see [this question](https://stackoverflow.com/questions/9643626/does-javascript-support-64-bit-integers). – slauth Aug 18 '21 at 09:53
  • @slauth so the json parser of spring (jackson) already uses the js 53-bit integer and approximates the value like in your linked question described? – chaosKP Aug 18 '21 at 10:11
  • I would have thought that the json which is generated on java side should still be correct and only inside the js code the value would be wrong. – chaosKP Aug 18 '21 at 10:16
  • @chaosKP you are right, the error only occurrs when *parsing* the JSON. Most likely your browser's devtools console is doing that. Better try with `curl` when in doubt. – slauth Aug 18 '21 at 10:24

1 Answers1

0

Like @slauth said, problem is the js 53 bit integer implementation.

chaosKP
  • 41
  • 3