Java Community Process Approves JSON API Spec Request
The stated goal of JSR 353, Java API for JSON Processing, is to develop an API to produce and consume JSON text "in a streaming fashion" similar to the StAX API for XML, and to build a Java object model for JSON text using API classes similar to the DOM API for XML.
The spec lead for JSR 353 is Jitendra Kotamraju, a principal member of the technical staff at Oracle and a former staff engineer at Sun Microsystems. According to his java.net profile, Kotamraju has been working with a range of Java Web services, including JAXRPC, JAXWS, SAAJ. Word began circulating last spring via Kotamraju's blog that Oracle wanted to include a Java API for JSON in the Java EE platform.
This JSR is meant to be available as a standalone spec, but it's also aiming or inclusion in the Java Enterprise Edition 7 platform. The JSR lists one "non-goal" of the project: "binding the JSON text to Java objects and vice versa."
The Executive Committee (EC) of the JCP approved the JSR with 10 yes votes and six abstentions. IBM voted for the JSR, but included a comment with that vote that seems to criticize Oracle's licensing practices. That comment reads, in part:
"IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model."
SouJava, the Brazilian Java Users Group that joined the EC early last year, also voted yes with a comment:
"JSON is clearly an important topic for our members and to the Java Community in general. This JSR will hopefully attract developers from existing implementations and we expect the spec lead to work hard to involve those developers and the broader community in the EG formation. From what we saw from the spec lead at JavaOne, this is already happening, what is very positive."
Newly elected EC member Twitter voted for the JSR without comment, as did Oracle, HP, Fujitsu, the Eclipse Foundation, Goldman Sachs, Intel and Credit Suisse.
The final version is expected in Q3 of this year.