Double value loses its decimal point after being converted to string

[chenhongbao]

I find the floating-point number loses its decimal point after it is converted to a string, when the number doesn't have a fractional part. And it might cause exception when the string is parsed back to an JSON object in another context (C++).

I have code like the below.

JSONObject o = new JSONObject();
		
double d = 1960;
int i = 1980;
		
o.put("DOUBLE", d);
o.put("INT", i);
		
String text = o.toString(4);
System.out.println(text);

Variable d is a double. So it is expected to have a decimal point so that I can parse it into a floating-point number. But the output is the below, which omits the decimal point.

{
    "DOUBLE": 1960,
    "INT": 1980
}

I parse it with another JSON library in C++ then. It throws an exception when I get the 'DOUBLE' as double, as it should be. The field is parsed as an integer in the end.

I track down to the code between line 997 and 1001 in JSONObject.java.

    public static String numberToString(Number number) throws JSONException {
        if (number == null) {
            throw new JSONException("Null pointer");
        }
        testValidity(number);

        // Shave off trailing zeros and decimal point, if possible.

        String string = number.toString();
        if (string.indexOf('.') > 0 && string.indexOf('e') < 0
                && string.indexOf('E') < 0) {
            while (string.endsWith("0")) {
                string = string.substring(0, string.length() - 1);
            }
            if (string.endsWith(".")) {
                string = string.substring(0, string.length() - 1);
            }
        }
        return string;
    }

I could fix the problem, but I still have two questions:

1. Why does it shave off trailing zeros and decimal point ?
2. Is it a bug or you make it with intention ?

[johnjaylward]

It is intentional as JSON does not have typed numbers. If a C++ parser is erroring, then there is a bug there, not in this library.

1980 and1960 are both valid JSON Numbers. The calling library (Java, C++, ruby, etc.) should handle any type conversions gracefully as needed by the language.

[GedMarc]

This is could be the common issue....

Some programming languages such as Javascript cannot support numbers with > 53-bits. This can be easily examined by running a command similar to: (90071992547409921).toString() in a browser console or by running the following JSON snippet through your JSON parser.

{"id": 10765432100123456789, "id_str": "10765432100123456789"}

The solution
The first thing to do is to attempt to decode the JSON snippet above using your production code parser. Observe the output to confirm the ID has not lost accuracy.

If your code converts the ID successfully without losing accuracy you are OK but should consider converting to the _str versions of IDs as soon as possible.
If your code loses accuracy, convert your code to using the _str version. If you do not do this your code will be unable to interact with the Twitter API reliably.
In some language parsers, the JSON may throw an exception when reading the ID value. If this happens in your parser you will need to ‘pre-parse’ the data, removing or replacing ID parameters with their _str versions.