jsonvalue.cutOffPointZero(String s)

[239]

When setting values to floating point numbers which end on ".0" like this jsonobject.set("test", (double) 21.0) then the number is automatically truncated to an integer: {"test":21} If I set a double value then I would expect the result to be a double and not an integer. I had to remove this method in my project to be able to differ between integer/long and float/double. Is this method essential in some way?

[ralfstx]

This change has been made in 3e3918e. IIRC, this was done because the trailing .0 can significantly inflate the created JSON without providing any additional information (1.0 === 1 in JavaScript).

Could you explain why the trailing zeros are important in your project?

[239]

I need a simple JSON-editor that can be used to modify values without changing their types. So the editor should constrain new values based on the old values like this: {"name":"239"} can be changed to {"name":"ralfstx"} but not to {"name":239} {"id":239} can be changed to {"id":932} but not to {"id":2.39} {"length":0.5} can be changed to {"length":1.0} but not to {"length":1} The problem in the last case is that the editor would constrain new values to integers the next time if the fraction part is left out.

[ralfstx]

modify values without changing their types

JSON defines the types string, number, array, object, and the literals false, true, and null. It does not differentiate between floating point and integer. Hence in JSON terms, changing 1.0 to 1 does not change the type.

[239]

You are right, there are just numbers in JSON and it does not make any distinction between integer and floating-point numbers. But it's not possible to write a JSON-file like this even though it's a valid array:

"sensor2": [
    0.9963,
    0.9991,
    1.0000,
    1.0017,
    1.0055
]

[ralfstx]

Even if the implementation was changed as suggested, you'd get 1.0 instead of 1.0000 ;-)

Anyway, I see your point. The fractional digits may contain relevant information, e.g. the value's precision. The JSON standard allows to convey this information, as it does not dictate to truncate zeros, however, minimal-json does not allow creating numbers in this format.

I think that BigDecimal is the correct Java type for handling numbers with arbitrary precision, so this comes down to #11.

[239]

In my case 1.0 is sufficient, though. In my opinion it looks more consistently like this:

[
    0.25,
    0.5,
    0.75,
    1.0,
    1.25
]

than this:

[
    0.25,
    0.5,
    0.75,
    1,
    1.25
]

[ralfstx]

I can understand this requirement. There seem to be use cases for both modes, truncating and not truncating zeros.

Maybe this should be configurable, e.g. JsonValue.writeTo( writer, config )? Could be related to #10.

[ralfstx]

Maybe an additional precision or format parameter in the valueOf method could help?