Skip to main content

[json-processing-spec users] Introduction and some initial user thoughts.

  • From: David Illsley < >
  • To:
  • Subject: [json-processing-spec users] Introduction and some initial user thoughts.
  • Date: Sat, 24 Mar 2012 19:13:11 +0000

Hi,
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 
shared pre-EDR.

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 
useful.

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:

DirectWriter.objectWriter(writer)
               .string("firstName", "John")
               .string("lastName", "Smith")
               .number("age", 25)
               .array("phoneNumber")
                 .object()
                   .string("type", "home")
                   .string("number", "212 555-1234")
                   .end()
                 .object()
                   .string("type", "fax")
                   .string("number", "646 555-4567")
                 .end()
               .end()
             .end()
             .close();

Implementation and example at 
https://github.com/davidillsley/scratch/tree/master/jsonp-wrap/src/org/i5y/json/wrap

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.

2. Numbers.

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.

Questions:
  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,
David

[json-processing-spec users] Introduction and some initial user thoughts.

David Illsley 03/24/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

Tatu Saloranta 03/25/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

Jitendra Kotamraju 03/25/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

David Illsley 03/25/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

Tatu Saloranta 03/25/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

David Illsley 03/29/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

Tatu Saloranta 03/29/2012
 
 
Close
loading
Please Confirm
Close