DevoxxFR 2014 : JEE 7, la relève ?

La version 7 de JEE, réalisée de juin 2013, apporte son lot de petits add-ons bien sympathiques. Loin d’être révolutionnaire, Jee 7 montre que la version entreprise de Java n’est pas morte et reste à l’écoute de la communauté. Toujours dans une lignée de bon père de famille, on reste compatible avec les versions antérieures  même si ça oblige à faire des wrapper de classes, pour JMS 2.0 par exemple.

La super présentation d’Arun Gupta faite à Devoxx France 2014, disponible sur slideshare, présente les 50 avancées les plus importantes en termes de JEE. Je vous propose de nous limiter aux plus significatives et surtout aux plus utiles dans nos développements quotidiens.

  1. CDI enfin activé par défaut : une évolution qui n’aurait jamais dû être nécessaire ; le fichier vide beans.xml n’est plus obligatoire pour activer l’injection par CDI. Que faire à part de l’injection de dépendance aujourd’hui ? Des new partout ? Non merci !
  2. Bean Validation permet de mettre des pré et post conditions sur les méthodes. Un moyen simple d’ajouter un test en entrée de méthode, juste pour être sûr que les arguments sont à priori corrects. Les gens connaissant le langage Eiffel  vont être contents de voir que le petit frère Java n’oublie pas ses racines objets.
  3. Interceptors permet maintenant de définir un ordre d’appel, auparavant laissé à la main du conteneur : simple et pratique.
  4. JPA enfin des propriétés standards pour initialiser les schémas de manière identique pour les différents ORM. Et non, tout le monde n’utilise pas Hibernate. Par exemple, OpenJPA est utilisé par les projets Apache comme Tomee mais aussi par Websphere Application Server. On attend encore des propriétés standards pour le réglage des logs…
  5. JPA encore avec des index ajoutés sous forme d’annotations dans les entités. Pratique sur des petits projets même si je préfère versionner mon schéma avec des outils comme liquibase/flyway.
  6. JTA évolue pour rendre plus accessibles les transactions aux développeurs. Une annotation pour paramétrer quoi faire face aux différentes exceptions et une autre pour intégrer un bean dans une transaction. Le message est clair : développeurs, vous ne pouvez pas ignorer la prise en charge des transactions !
  7. JMS change après presque 10 ans d’immobilisme. C’est l’une des API les plus utilisées depuis les premières versions de J2EE. On passe aux annotations (le XML est toujours possible, ma chère compatibilité !) et on réduit le boilerplate code. On sécurise également la prise en charge des exceptions grâce à « l’autocloseable » (intraduisible).
  8. Servlet/ Websocket : pris en charge dans le code standard : simple et efficace.
  9. JSF : intégration de flow natif.
  10. JAX-RS intègre un client. Non Jersey et resteasy ne faisaient pas partie de JEE. L’avantage du standard est qu’il repose sur l’intégration avec toute la stack : interceptors, asynchronisme, filtre.
  11. JSON – certains se plaignaient de ne pas avoir de parser de bas niveau pour du JSON ? C’est chose faite. A l’image de SAX pour le XML, nous avons maintenant JSON-P.  Pour le marshalling en objet (image de DOM pour le XML) la JSR-353 reste de vigueur.
  12. Batch, c’est du tout nouveau… si vous ne connaissez pas Spring Batch. Les concepts sont les mêmes avec plus de simplicité et de flexibilité.
  13. Default resources : des ressources par défaut sont affectées aux noms JNDI de datasource, ConnectionFactory de JMS, ManagedThreadFactory. Pratiques en développement mais dangereux et un peu déresponsabilisant pour les développeurs n’ayant pas la vision DevOps.

Et maintenant on fait comment ? On migre ? On attend ?

Je conseillerais pour les nouveaux projets de partir sur la version 7 car elle est, et restera, standard. L’écosystème est en marche et les serveurs d’applications compatibles arrivent. Sans être encore à maturité, cela ne saurait tarder. Aujourd’hui seuls Widfly (anciennement Jboss) et Glassfish sont compatibles. Weblogic le sera dans l’année. Aucun plan pour Apache TomEE et Wepshere Application Server… pour le moment !

Pour les projets existants en JEE 6, la marche à franchir n’est pas très haute et le coût pourrait vite être rentabilisé par les avancées qui seront proposées par les serveurs d’applications et les nouvelles JVM.

Enfin, pour les autres (JEE 5 ou antérieur, Java + spring, etc) la migration sera longue et difficile. Envie d’une petite réécriture ? Bienvenue dans le XXIe siècle !

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !