As reported on InfoQ, Oracle has announced the first set of features targeted for Java 9. This includes a new API for JSON, which is being developed as JEP 198.

Historically, Java has been a platform of choice for processing XML, but in recent years the world has moved further and further towards JSON data being consumed and returned by simple REST-based web services. Java has fallen somewhat behind the curve of other languages, and it is this deficit that JEP 198 hopes to address.

This new initiative is not taking place in a vacuum. The recent Java EE 7 standard has support for defining the media type that a handler method will return, via the @Produces annotation. Containers are at liberty to support "application/json" as a suitable return type, but this does

require suitable serializers to be written by the application developer. In the absence of standardization the resulting JSON generation code is not portable across JSON provider libraries.

EE 7 also introduced JSR 353, also known as JSON-P, as a way to bring basic support for JSON parsing into the EE landscape. Like many other EE standards, JSR 353 is "standalone" and can also be integrated into SE applications.

The release of Java SE 8 provided another way to engage with JSON in a standards-compliant way; Java 8 ships Nashorn, a new implementation of Javascript. This implementation provides JSON.parse() and JSON.stringify() by default. This means that by using the script engine

from within Java, the Nashorn support for JSON can be accessed. However, doing so requires a roundtrip into Nashorn and back again, i.e. there is no Java-language level support for JSON parsing.

With this groundwork in mind, as well as the ongoing work in JEP 198, InfoQ spoke to two JSON early adopters, Java experts and community members: Sven Reimers (NetBeans Dream Team) and Mohamed Taman (leader of the Egyptian JUG), for their views of the current state of JSON support and their hopes for the future.

InfoQ: Can you explain in detail how you're currently making using of JSR 353 support in your project? Which libraries and tools have you found the most useful?



Sven: As part of major systems interface (in desing and prototyping phase) we are actually using JavaEE 7, REST, JSON. Due to this we sometimes end up doing parsing / processing still by hand, if the automagically provided conversion fails on us. I have just read a post

by Adam Bien about how this paradigm kills DTO in Java EE.

At the moment we are not using other libraries besides JSON parsing as it is built in Groovy, with some gradle magic.



Mohamed: I am using JSON-P (JSR 353) in two places:

1) With configuration files as it can help with complex configuration structure better than

properties file, both for client and server components.

2) When returning, as a data type for my REST clients especially mobile clients and

angularJS based framework solutions I have delivered to customers.

The artifact I am using is:

<dependency> <groupId>org.glassfish</groupId> <artifactId>javax.json</artifactId> <version>1.0.4</version> <type>jar</type> <scope>compile</scope> </dependency>

I can recommend JSONpad for building, validating and converting to XML visually, it helps to build your JSON configuration then you can use the library to construct this JSON context.



InfoQ: What shortcomings and drawbacks (if any) have you found with the current support?

Sven: So far it seems to fit our use case quite well. The only thing probably missing is something quite like JAXB for JSON, but with all the non-existence of JSON schema usage I am not sure that this will be worth it.

Mohamed: Support for JAXB style type-safe data binding, as always we need to serialize data to JSON from JPA entity beans directly using annotations, and not doing so manually.



InfoQ: What have you heard about JEP 198 and the support that it hopes to deliver? Have you tested any early builds yet? if not, is that something you'd be interested in as the technology matures?

Sven: I've read the JEP and I see that the provided funtionality in addtion to JSR 353 is interesting (e.g.tree api). On the other hand is the added functionality worth a JDK extension? Why not put the JEP into the next jsonp spec?

Mohamed: It will be great to add this lib to core JDK, as we need it on the core level especially for complex configurations without the need for external lib. Also if it is added to JDK I would like to see it exposed to all other platforms without duplication including Java ME and Java EE.

I haven't tried it in early build yet. Nevertheless, it will be very interesting to look at and test the early builds.



InfoQ: What features and functionality would you be most keen to see Oracle deliver as part of this project?

Sven: Not sure what is the added value over JSON-P.

Mohamed: Support for JAXB style type-safe data binding and JSON validation.



InfoQ: Any other feedback or comments?

Sven: Not really. We are still in the early stages, so maybe later on.

Mohamed: Add future features to support conversion from XML to JSON and vice versa.