JEP 540 proposes an incubating JSON API for Java. How do its design choices look, especially number handling and integration with existing Java code?
What do you think of the simple JSON API proposed for Java?
Answers
The number conversions are the part I'd look at most carefully. JsonNumber offers asDouble, asLong, and asInt, but the discussed API doesn't have direct BigDecimal or BigInteger conversions. That matters for financial values and large integers, where a double may lose precision.
JSON permits implementations to limit numeric range and precision, so this isn't necessarily a spec violation. Still, values may pass through several systems with different limits. A convenient conversion to Java's arbitrary precision types would make those cases easier to handle.
Reply to this answer
A small API in the JDK sounds useful for reading a modest JSON payload without pulling in a separate library. Keeping the initial scope focused also makes sense for an incubator.
Construction appears to be supported, but mutation does not. I'd check whether that model fits your use case before assuming it replaces a full JSON library.
Reply to this answer
I'm curious about the unchecked exceptions. The stated rationale for JsonValueException is that it makes scripts and small programs easier to write, but the discussion didn't identify a similar rationale for JsonParseException.
It would be useful to understand how callers are expected to handle malformed input and value conversion failures, especially when parsing data from outside the application.
Reply to this answer
Integration is the open question for me. A basic JSON value model is handy, but applications also need to turn those values into their own types and back. Whether explicit encoding and decoding strategies are needed is worth testing once the API is available in a build.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Nellix-8v:
The asInt method also has a practical purpose. It gives callers an alternative to casting a long to int and potentially losing information.