Comme le reportait InfoQ, Oracle a annoncé le premier lot de fonctionnalités qui ciblent Java 9. Cela inclut une nouvelle API pour JSON en cours de développement comme JEP 198.
Historiquement, Java a été la plate-forme de choix pour les traitements XML, mais au cours des dernières années, le monde a évolué de plus en plus vers des données en format JSON qui sont consommées et retournées par de simples services web REST. Java a accumulé un certain retard par rapport à d'autres langages et c’est ce déficit que la JEP 198 espère rattrapper.
Cette nouvelle initiative ne provient pas du vide. Le récent standard Java EE 7 supporte la définition de type de retour des méthodes handlers via l'annotation @Produces. Les conteneurs sont libres de soutenir "application/json" comme un type de retour approprié, mais cela exige l'écriture de sérialiseurs appropriés par le développeur de l'application. En l'absence de normalisation, le code généré JSON résultant n’est pas portable entre les bibliothèques des fournisseurs JSON.
EE 7 a également introduit JSR 353, baptisé JSON-P, comme un moyen d'apporter un soutien de base pour l'analyse JSON dans le paysage EE. Comme beaucoup d'autres normes EE, la JSR 353 est "autonome" et peut également être intégrée dans les applications SE.
La version 8 de Java SE fournit une autre manière de collaboration avec JSON conformément aux normes ; Java 8 expédie Nashorn, une nouvelle implémentation Javascript. Cette implémentation fournit JSON.parse() et JSON.stringify() par défaut. Cela signifie qu'en utilisant le moteur de script à partir de Java, le support Nashorn de JSON est accessible. Toutefois, cela nécessite un aller-retour vers Nashorn, c’est-à-dire qu'il n'y a pas un support Java par défaut pour l'analyse JSON.
Avec ce travail de base à l'esprit, ainsi que les travaux en cours dans JEP 198, InfoQ a interviewé deux adopteurs précoces de JSON, des experts Java et membres de la communauté : Sven Reimers (NetBeans Dream Team) et Mohamed Taman (Leader de la JUG égyptienne), pour avoir leurs points de vue sur l'état actuel de support de JSON et leurs projections pour l'avenir.
InfoQ : Pouvez-vous nous expliquer en détail comment le support de la JSR 353 vous aide actuellement dans vos projets ? Les bibliothèques et les outils que vous avez trouvés les plus utiles ?
Sven : Dans le cadre de l'interfaçage entre la plupart des systèmes (en phase de design et de prototypage), nous sommes en train d’utiliser JavaEE 7, REST, JSON. Pour cette raison, on aboutit parfois à faire l'analyse/le traitement encore manuellement si la conversion automatique fournie échoue. Je viens de lire un article d'Adam Bien sur la manière dont ce paradigme tue les DTO en Java EE.
Pour le moment, nous n’utilisons pas d'autres bibliothèques en dehors de JSON parsing vu qu'il est intégré en Groovy avec un peu de magie gradle.
Mohamed : J’utilise JSON-P (JSR 353) dans deux endroits :
1) Avec les fichiers de configuration car il peut aider avec sa structure de configuration complexe mieux que les fichiers properties, autant pour les composants client que pour les composants serveur.
2) Lors du retour, comme un type de données pour mes clients REST en particulier les clients mobiles et les solutions basées sur le framwork AngularJS que j’ai livrées aux clients.
L'artefact que j’utilise est :
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.json</artifactId>
<version>1.0.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
Je peux recommander JSONpad pour la construction, la validation et la conversion en XML visuellement, il aide à construire votre configuration JSON, vous pouvez utiliser cette bibliothèque pour construire le contexte JSON.
InfoQ : Quelles sont les failles et inconvénients (le cas échéant) que vous avez trouvés avec le support actuel ?
Sven : Jusqu'à présent, il semble correspondre tout à fait à notre cas d'utilisation. La seule chose qui manque probablement est comme JAXB pour JSON, mais avec toute la non-existence d’utilisation de schéma JSON, je ne suis pas sûr que cela vaille la peine.
Mohamed : Le support du style type-safe de JAXB pour le data binding, comme toujours, nous devons sérialiser des données en JSON des beans entités JPA directement en utilisant les annotations et non pas manuellement.
InfoQ : Avez-vous entendu parler de la JEP 198 et du support qu'elle espère offrir ? Avez-vous déjà testé un build ? Sinon, est ce que cela représenterait un intéret pour vous au fur et à mesure que la technologie murisse ?
Sven : J’ai lu la JEP et je vois que la fonctionnalité fournie en plus de la JSR 353 est intéressante (ex l'api tree). D'autre part, est-ce la fonctionnalité ajoutée vaut comme extension JDK ? Pourquoi ne pas mettre la JEP dans la prochaine spécification jsonp ?
Mohamed : Cela serait formidable d’ajouter cette lib à la base de JDK, comme nous en avons besoin sur le niveau de base en particulier pour les configurations complexes sans avoir besoin de lib externe. Aussi, si elle était ajoutée au JDK, j’aimerais la voir exposée dans toutes les autres plates-formes sans duplication y compris Java ME et Java EE. Je n’ai pas encore essayé les premiers builds. Néanmoins, il serait très intéressant de les regarder et les tester.
InfoQ : Quelles sont les caractéristiques et fonctionnalités que vous aimeriez qu'Oracle livre dans le cadre de ce projet ?
Sven : Pas sûr de la valeur ajoutée par rapport à JSON-P.
Mohamed : Le support du binding type-safe comme JAXB et la validation JSON.
InfoQ : D'autres remarques ou commentaires ?
Sven : Pas vraiment. Nous sommes encore dans les premières phases, alors peut-être plus tard.
Mohamed : L’ajout de nouvelles fonctionnalités pour supporter la conversion de XML en JSON et vice versa.