[json-processing-spec users] Introduction and some initial user thoughts.
- From: David Illsley <
- Subject: [json-processing-spec users] Introduction and some initial user thoughts.
- Date: Sat, 24 Mar 2012 19:13:11 +0000
As a quick introduction, I'm a server side developer who dabbles with web
projects and JSON, and I have a pretty deep history with XML and the DOM. I'm
also part of the London Java Community Adopt-a-JSR group for this JSR, and
I'm looking forward to seeing this JSR complete, and us having a better JSON
story for Java.
One of the things the LJC is keen on is openness and transparency in the JSR
process, so I'm really happy to see some API and design related documents be
I've taken a look at the currently available API, and have some thoughts and
questions. Hopefully the remainder of this email will be at least a little
First off, I think the current API shows a lot of promise. It's important
that this API is one that developers enjoy using (unlike the DOM in my
experience), and I think there's plenty of scope for that here.
There are 3 areas of suggestions/questions I have at the moment.
1. Method chained API
JsonWriter has a comment wondering if some form of method chaining is
desirable. I think it is. I've sketched out the kind of thing I'd want to
actually use based on wrapping the current API, and it results in the
following, which I think is pretty clean and clear:
.string("number", "212 555-1234")
.string("number", "646 555-4567")
Implementation and example at
Everyone could write their own version of this as it's not that much code,
but it'd be better if they didn't have to.
In order to explore the problem space, I knocked together my own API/parser a
little while ago, and I kindof punted on dealing with numbers because it's
not obvious what to do. On the writer-side, simply taking Number seems to
work. On the reader side, particularly for application (vs library) users,
the user probably knows what precision they want, and are happy to ask for
it. Expecting users to do some if/else instanceof tree + conversion every
time they get a number seems like a poor solution.
One option which appeals to me is to add asInt() asFloat() asDouble() etc to
JsonNumber. The would simply do the bolierplate transformations, possibly
losing precision, but giving the app developer what they want.
a. What are the current thoughts on how to deal with numbers?
b. For the library/process arbitrary document case, is there a performant,
concensus algorithm to decide which of float/double/BigDecimal to use, and is
specification of one in-scope for this JSR?
3. Tree navigation, instanceof, and nulls.
My main pain points with the XML DOM are around constant instanceof checks
and null-checks when navigating the tree.
When you know what you're looking for, XPath is pretty much required to keep
your code from becoming spaghetti. I see a similar danger of requiring
constand null-checks naviagting a tree here.
What are your thoughts on having some kind of path api (could be as simple as
<T extends JsonValue> JsonObject.getPath(String path, Class<T> clazz) to make
it simple to grab some nested information?
instanceof checks and casting also seem to be common with the current API if
you're walking an arbitrary tree and inspecting the contents. I know this is
less common with JSON than with XML, but I do think it's worth making easier.
What do you think of adding a JsonValueTypeEnum getType() to JsonValue?
All the best,