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.
properties file, both for client and server components.
angularJS based framework solutions I have delivered to customers.
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.json</artifactId>
<version>1.0.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
InfoQ: What shortcomings and drawbacks (if any) have you found with the current support?
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?
InfoQ: What features and functionality would you be most keen to see Oracle deliver as part of this project?
InfoQ: Any other feedback or comments?