Suporte Nativo para JSON no Java 9

Tal como reportado no InfoQ, a Oracle anunciou os próximos recursos a serem incluídos no Java 9 e entre eles está incluso uma nova API para JSON, que está sendo desenvolvida como JEP 198.

Historicamente o Java tem sido a plataforma favorita para processamento de XML, mas nos últimos anos há uma tendência para o uso de dados no formato JSON gerados por serviços REST, de tal modo que o Java ficou para trás em comparação com outras linguagens e este é o deficit que a JEP 198 espera cobrir.

Esta nova iniciativa não está ocorrendo de forma isolada. O recente Java EE 7 tem suporte para definir o media type que um método retornará usando a anotação @Produces. Os containers tem a liberdade para suportar o tipo "application/json" como um retorno adequado, porém existe a necessidade do desenvolvedor escrever serializadores para tratar o conteúdo. Na ausência da padronização do conteúdo JSON gerado, não é possível ter compatibilidade do código gerado entre as bibliotecas JSON.

Além desta iniciativa, o Java EE 7 também trouxe a JSR 353 que é conhecida como JSON-P e oferece suporte básico para a análise de JSON em ambientes EE. Assim como muitos outros padrões EE, a JSR 353 é isolada e pode ser utilizada em aplicações SE.

O lançamento do Java SE 8 trouxe uma outra maneira compatível com os padrões para trabalhar com JSON; o Java 8 trouxe o Nashorn, uma nova implementação Javascript. Essa implementação prove os métodos JSON.parse() e JSON.stringify() por padrão. Isso significa que ao utilizar este mecanismo de script a partir do Java, é possível acessar o suporte JSON que o Nashorn oferece. Ao utilizarmos estes métodos a partir da JDK, é feito o processamento no Nashorn e retornado para o Java, em outras palavras, não existe suporte nativo para a análise do JSON na linguagem Java.

Com todo este trabalho fundamental executado, assim como o trabalho em andamento na JEP 198, o InfoQ.com conversou com os dois usuários pioneiros no formato JSON, especialistas Java e membros da comunidade: Sven Reimers (NetBeans Dream Team) e Mohamed Taman (líder do JUG do Egito), sobre a sua visão do estado atual do suporte JSON e o que esperam no futuro.

InfoQ.com: Poderiam explicar em detalhes como estão utilizando o suporte da JSR 353 em projetos? Quais bibliotecas encontraram e acharam mais úteis?

Reimers: Na maior parte das interfaces dos sistemas (em fases de projeto e protótipos) estamos atualmente usando JavaEE 7, REST e JSON. Quando ocorre alguma falha na conversão automática, acabamos fazendo a análise e processamento manualmente. Acabo de ler uma postagem de Adam Bien sobre como este paradigma mata o DTO no Java EE. No momento não estamos utilizando outras bibliotecas além do processamento de JSON em Groovy.

Taman: Estou utilizando JSON-P (JSR 353) em duas situações:

1. Em arquivos de configuração, por tornar mais fácil o trabalho com estruturas mais complexas que arquivos de propriedades, tanto no cliente quanto no servidor;
2. Ao retornar dados para os clientes REST, especialmente para os aplicativos móveis e soluções baseadas no framework AngularJS.

O artefato que estou usando é:

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

Posso recomendar o JSONpad para construção, validação e conversão para XML visualmente, facilitando a criação de documentos JSON, então é possível utilizar a biblioteca para inicializar seu contexto JSON.

InfoQ.com: Quais são as dificuldades e desvantagens (se alguma) que encontraram no suporte atual?

Reimers:Até agora parece que se encaixa muito bem no nosso caso. A única coisa que provavelmente está faltando é algo como JAXB para JSON, dado que não existe validação de esquemas para JSON, não tenho certeza se isso valeria a pena.

Taman: Suporte para conversão segura dos dados como no estilo JAXB, porque sempre precisamos serializar os dados das entidades JPA para criar o conteúdo JSON.

InfoQ.com: O que ouviram a respeito sobre a JEP 198 e o suporte que será fornecido? Fizeram algum teste nas versões recentes? Se não, é algo que poderia interessar conforme a tecnologia fique mais madura?

Reimers: Li a JEP e vi que as funcionalidades oferecidas além da JSR 353 são interessantes (ex.: api para trabalhar com árvores). Por outro lado, funcionalidades adicionais valem uma extensão da JDK? Por que não colocar a JEP na próxima especificação JSON-P?

Taman: Vai ser ótimo adicionar esta biblioteca ao núcleo da JDK, precisamos dela especialmente para trabalhar com configurações complexas sem a necessidade de componentes externos. Além disso, se ela for adicionada ao JDK, gostaria de encontrá-la nas plataforma Java ME e Java EE. Não testei os pacotes mais recentes, no entanto, vai ser muito interessante testá-los.

InfoQ.com: Quais são os recursos e funcionalidades que ficariam mais entusiasmados de ver a Oracle fornecer como parte deste projeto?

Reimers: Não tenho certeza o que adicionaria valor ao JSON-P.

Taman:Suporte para conversão segura dos dados como no estilo JAXB e validação JSON.

InfoQ.com: Algum outro feedback ou comentário?

Reimers: Não. Estamos nos estágios iniciais, talvez em outro momento.

Taman: Adicionar recursos futuros para suportar a conversão do XML para JSON e vice-versa.