This blog is about my observations and thoughts related to software development. These observations include tips and tricks that I have learned, solutions to problems I have faced, and other concepts I have found interesting and useful. This blog is intended to provide information to help other developers facing the same issues as well as providing me a method to document things in a well-known location for my own future reference.
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.
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.createParserFactory().createParser(). This parser is optionally configured to use certain features and supports several state events including
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
JsonArray as well as
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
JsonArray is similar to
JsonObject in terms of immutability but is a
List of values.
JsonBuilder is used to "build
JsonArray from scratch." It allows for method chaining and is "type-safe" in terms of not allowing mixing of objects and arrays.
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.
Original posting available at http://marxsoftware.blogspot.com/ (Inspired by Actual Events)