I went to Parc 55 Mission to see Jitendra Kotamraju's (Oracle) presentation "JSR 353: Java API for JSON Processing." Kotamraju is the JSR 353 specification lead, so it's safe to assume he knows something about this "JSON for Java" JSR. I have written about Groovy's impressive JSON support and have looked forward to Java having something like this.
JSON (JavaScript Object Notation) in Java has been a popular topic for some time now. It is refreshing to see that JSR 353 ("Java API for JSON Processing") is in Early Draft Review and looks likely to be part a forthcoming Java EE release.
Kotamraju began with a brief overview of JSON and looking at an alternate (JAX-RS) use case of JSON before moving onto coverage of JSR 353 and JSON processing in Java. He described JSON as it's typically described: "lightweight data exchange format" that is "easy for humans/machines to read and write." One of his bullets emphasized that JSON is textual and fairly concise. He showed a slide with numerous "popular web sites" that provide "RESTful web services" using JSON.
Kotamraju had a slide focusing on the JSON used with Amazon Cloud Services. Another slide focused on the same for Twitter Search.
Kotamraju first showed slides on JAX-RS that showed exposed services returning XML via JAXP and JAXB. He then introduced the idea of using JSON ("application/json") rather than XML ("application/xml").
He stated that while the JAX-RS specification doesn't currently support JSON, many of the JAX-RS implementations do support JSON.< The downside to JSON being a nonstandard feature of JAX-RS implementations includes work-arounds used to make this work (such as converting JAXB to JSON or converting JAXB to XML to JSON), limitations in some implementations, and the need to bundle extra libraries. Standardizing JSON support would help make its use leaner and cleaner and more consistent.
The JSON standard support is encapsulated in JSR 353. This JSR currently includes a "streaming API to produce/consume JSON" and an "object model API to represent JSON." The Expert Group for this JSR includes Oracle, RedHat, and Twitter as well as individual and community members.
Kotamraju showed a bubble chart showing the states of a JSR with the current state of JSR 353 (Early Draft Review) highlighted. JSR 353 is implemented as a java.net open source project. They have mailing lists and an issue tracker, both of which Kotamraju provided URLs for on one of his slides. The JSR 353 reference implementation (jsonp) falls under the "GlassFish umbrella."
Kotamraju had a nice slide summarizing (two bullets each) the characteristics of the two JSR 353 APIs (Steaming API and Object Model API). He then went into more detail on each of these two APIs.
The JSR 353 Streaming API is similar to StAX and includes JsonParser for "parsing JSON in a streaming way from input sources." An instance of JsonParser is acquired via Json.createParser() or Json.createParserFactory().createParser(). This parser is optionally configured to use certain features and supports several state events including START_OBJECT, END_OBJECT, KEY_NAME, and VALUE_STRING. Kotamraju pointed out that the Streaming API is very low-level and not type safe (difficult to be type safe with String-oriented things like this!).
The Streaming API also includes a JsonGenerator that "generates JSON in a streaming way to output sources" and is "similar to StAX's XML StreamWriter.
The JSR 353 Object Model API core classes include JasonObject and JsonArray as well as JsonBuilder, JsonReader, and JsonWriter.
JsonObject is immutable and "holds name/value pairs" that are accessible as Map<String, JsonValue>. The JsonValue returned from the "value" portion of that map supports a getNames() method. JsonArray is similar to JsonObject in terms of immutability but is a List of values.
JsonBuilder is used to "build JsonObject and JsonArray from scratch." It allows for method chaining and is "type-safe" in terms of not allowing mixing of objects and arrays.
JsonWriter writes JsonObject and JsonArray to output source and uses pluggable JsonGenerator. There will be optional configuration features such as "pretty printing" (what's pretty will be up to implementation) and single-quote strings.
The JSR 353 Expert Group still needs to define equals/hashcode semnatics, how to handle exceptions, and other miscellaneous to-do items. Kotamraju encouraged attendees to try read more about JSR 353 and try out the reference implementation. He'd like to know if it's simple enough to understand and meets peoples' needs.
There were several points during this presentation when Kotamraju stated that the JSR 353 Expert Group would appreciate feedback on a specific design decision or other design choice. This again fits a common theme of JavaOne 2012 that community feedback is desired. This common goal of basing standards on developer feedback is the polar opposite of the old we-know-better-than-you expert committee approach of "you'll have EJB 1.x/2.x and you'll like it."
I liked that Kotamraju showed code samples embedded within his slides. I did this when I presented at Colorado Software Summit and received rave reviews from the audience members for doing so. It's certainly more work for the developer than simply showing code in the IDE, but it allows for greater focus on what's important and makes the sample code readily available for anyone reviewing the slides at a later time. I now regularly include sample code directly within slides of presentations that I give.
2 comments:
I guess this will help, but JSON has some fundamental problems which make it's use quite problematic. As one would expect from a 'non standardised' organically created `standard'.
Before spending time on creating these complex apis, the on-wire format needs work ...
a) some implementations use 'null' for null entries, others just don't include the value.
b) some implementations use empty lists for empty lists, others just don't include anything.
c) some implementations represent a list with one item as a non-list item, others as a single-item list.
d) some implementations represent strings quoted, others do not. Are escapes standardised?
e) most implementations handle inheritable and/or typed objects differently.
f) even the same implementation might not read/write the same formats of above. And break! Yes really!
g) it isn't really very machine or human readable for anything other than plain strings (just like xml isn't), quite bulky, and thus inefficient. "its better than xml" doesn't mean much ...
The problem is most of those issues mean that no interoperability is possible without having to manually hack around it all the time.
I did some JAX-RS stuff and apart from wasting a lot of time on it, had to manually override both it's and the android end with a specific implementation (and then configured specifically) before I got reliable interoperability. Web browsers just complicate matters even further.
The *only* thing going for JSON is that web browsers have a parser and generator for it 'built in' - but since that differs from browser to browser it's hardly a selling point either.
NotZed,
Thanks for your clear lucidity in explaining some issues that definitely do throw a damper on the enthusiasm for Java for JSON.
Dustin
Post a Comment