JavaOne 2012 : Oracle présente la spécification JSR 353

JavaOne 2012 : Oracle présente la spécification JSR 353
l’API Java pour rendre la manipulation des données JSON plus propre et cohérente

JavaOne 2012 s’est achevé hier. L’événement Java le plus important de l’année a levé le voile sur un nombre impressionnant de nouveautés, innovations et ambitions pour l’écosystème Java.

Oracle pendant ses sessions a présenté sa feuille de route pour le langage et les points sur lesquels l’entreprise travaille actuellement pour la prochaine version de Java, dont l’intégration des expressions lambda, du moteur JavaScript Nashorn, des annotations, de la nouvelle API « date and time » et bien plus.

Une session a été entièrement réservée au support du format JSON dans les futures versions du langage. Pour rappel, JSON (JavaScript Object Notation) est un format de données textuel, générique, dérivé de la notation des objets du langage ECMAScript. Il permet de représenter de façon structurée des informations.

L’avantage de ce format de données est qu’il est léger, flexible et facilement interprétable pour les machines. JSON a été adopté comme format d’échange par plusieurs sites Web populaires qui offrent des services Web RESTfull reposant sur le format, notamment Twitter et Amazon.

Actuellement, les développeurs Java utilisent différentes bibliothèques tierces pour produire et consommer des données JSON. Il devient donc nécessaire de normaliser une API JSON afin que les applications qui utilisent le format n’aient plus besoin de regrouper des bibliothèques externes. C’est le but de la spécification JSR 353 qui a été présentée par Oracle à JavaOne 2012.

La spécification JSR 353 : API Java pour le traitement de JSON, vise à rendre l’utilisation de JSON avec le langage plus légère, plus propre et plus cohérente. La spécification JSR 353 décrit actuellement une API (Streaming API) pour produire et consommer en continu des données JSON et une API (Object Model API) du modèle objet pour représenter JSON.

L’API Streaming implémentera les méthodes JsonParser pour la conversion et JsonGenerator pour la génération. L’API Object Model quant à elle, implémentera les méthodes JsonObject et JsonArray, ainsi que JsonBuilder, JsonReader et JsonWriter.

La spécification est actuellement au stade d’examen précoce et est mise en œuvre en tant que projet open source sur java.net. La fin de la phase d’examen précoce est prévue pour le 7 octobre prochain.

Le groupe d’experts travaillant sur cette spécification inclut les employés d’Oracle, RedHat, Twitter ainsi que des membres autonomes.

:fleche: Les détails sur la spécification JSR 353

Source : JavaWorld

Et vous ?

:fleche: Que pensez-vous de l'API JSR 353 ?

Citation:

... l’intégration des expressions lambda...

Ca c'est une bonne nouvelle :ccool:

S'ils partent de Jackson comme base, ils ne risquent pas de trop se tromper. Plus qu'à espérer qu'ils ne fassent pas comme pour XML un fouillis infâme d'interfaces dans tous les sens, surarchitecturé au possible.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 private void parseXmlFile() throws XmlParsingException { //get the factory DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); try { //Using factory get an instance of document builder DocumentBuilder db = dbf.newDocumentBuilder(); //parse using builder to get DOM representation of the XML file dom = db.parse("employees.xml"); }catch(ParserConfigurationException pce) { throw new XmlParsingException(pce); }catch(SAXException se) { throw new XmlParsingException(se); }catch(IOException ioe) { throw new XmlParsingException(ioe); } ///... }
Genre on crée des parsers à l'aide de factories sans trop savoir ce qui est retourné comme implémentation, avec 25 exceptions à gérer et un système de configuration key-value très peu pratique. Il y a des langages où cette fonction ci-dessus s'écrit en 1 ligne.

Enfin avec de la chance, depuis les premières versions du JDK ils auront eu le temps d'apprendre que rendre les choses straightforward, c'est bien aussi.