A quelques jours de la conférence JavaOne (16-19 mai à San Francisco), le comité JSR 244 a approuvé le 1er mai à l'unanimité (Final Approval Ballot) la spécification Java Platform Enterprise Edition 5 (Java EE 5) [http://jcp.org/en/jsr/results?id=3770]. Derrière cette spécification, il y a une ribambelle de spécifications qui sont approuvées dans la foulée : EJB 3.0 (JSR 220), JSF 1.2 (JSR 252), JSP 2.1 (JSR 245), JAX-WS 2.0 (JSR 224), etc. Java EE 5 est le successeur de J2EE 1.4. Le système de numérotation des versions a été revu pour se synchroniser avec celui de Java Standard Edition. En effet, pour la future version du langage et de la plate-forme standard, prévue pour cet automne, Java perd le « 2 » de Java 2 et le numéro de version perd son « 0 ». La version qui doit succéder à J2SE 5.0 ne s'appellera donc pas J2SE 6.0 mais Java SE 6. Du coup, la plate-forme entreprise ne s'appellera pas J2EE 1.5 mais Java EE 5 ! L'objectif de Java EE 5 est avant tout de simplifier le développement d'applications Java d'entreprise. Elle intègre bon nombre de fonctionnalités prévues pour EJB 3.0 telles que les annotations, la programmation de POJO (Plain Old Java Objects), l'injection de dépendances, de nouvelles API, de nouveaux frameworks... Java EE 5 fournira une bibliothèque standard de tags (JSTL, JSR 52), un Streaming XML Parser (StAX, JSR 173), les Web Services Metadata (JSR 181), une nouvelle version de JavaServer Faces (JSR 252). Le support des Web Services se renforce avec JAX-WS 2.0 (JSR 224) et JAXB 2.0 (JSR 222). EJB 3.0 est sans doute la spécification la plus attendue et constitue un pan entier de l'édifice Java EE 5. Cette spécification des composants transactionnels distribués devra relever un double défi : celui de la persistance des données et celui de la simplification des développements. Pour la persistance, EJB 3.0 propose un nouveau modèle de persistance, Java Persistence API, totalement inspiré d'Hibernate de JBoss. Pour simplifier les développements, EJB 3.0 exploite les annotations, une nouvelle fonctionnalité du langage Java 5.0. Ces métadonnées permettent à certains outils de générer des constructions additionnelles à la compilation ou à l'exécution ou encore de renforcer un comportement voulu au moment de l'exécution (comme la nature « sans état » d'un composant EJB). Les annotations simplifient considérablement l'écriture de programme. Pour réduire encore la complexité du développement, EJB 3.0 adopte le modèle de programmation POJO en utilisant les annotations. Désormais, tous les types de bean entreprise se réduisent à de simples POJO, de bons vieux objets Java, avec des annotations appropriées. Les annotations peuvent être utilisées pour définir l'interface métier du bean, les informations de mapping objet/relationnel, les références aux ressources, et tout ce qui peut être défini à travers des descripteurs de déploiement ou des interfaces en EJB 2.1. Les descripteurs de déploiement ne sont plus requis, l'interface « home » a disparu, et on n'a plus besoin d'implémenter une interface métier, le conteneur peut la générer. EJB 3.0 intègre également une approche Programmation Orientée Aspect (AOP) en introduisant la notion d'intercepteur (Interceptor) : c'est une méthode qui intercepte l'invocation d'une méthode métier sur un EJB Session ou un EJB Message-driven. EJB 3.0 propose même d'associer à un EJB Session une liste de classes Interceptors dont les méthodes intercepteront les invocations aux méthodes métier de cet EJB. Toutes ces nouveautés d'EJB 3.0 (conteneur léger, inversion de dépendance, AOP, mapping O/R...) ne sont pas sans rappeler ce qui existe maintenant depuis plusieurs années dans les frameworks open source tels que Spring, Hibernate, TopLink, Enhydra, etc... En fait, on pourrait résumer EJB 3.0 en l'équation EJB 3.0 = Spring + Hibernate + annotations. Les développeurs n'ont pas attendu la sortie de la spécification EJB 3.0, en chantier depuis 2003, pour se lancer dans le développement de POJO avec leur framework de persistance. Reste à savoir si ces développeurs basculeront sur EJB 3.0. D'autant que cette norme est déjà très controversée, notamment par les partisans de JDO (Java Data Object, JSR 243). Cet autre standard de persistance initiée par Sun se veut plus généraliste et fait déjà doublon avec EJB 3.0. Pour l'heure, EJB 3.0 arrive à point pour tenter de redorer le blason des EJB, plutôt mal en point, rattraper son retard sur les outils open source et reprendre une certaine avance sur la plate-forme .NET (qui ne dispose toujours pas de framework de persistance). Il ne manque plus que les implémentations Java EE 5 et EJB 3.0. Sun s'apprête à annoncer à JavaOne le premier serveur d'application Java EE 5, GlassFish [https://glassfish.dev.java.net/], en open source. JBoss, qui héberge en autres Hibernate, supporte déjà EJB 3.0 dans son serveur d'application JBoss Application Server. Oracle Application Server 10g (10.1.3) dispose également d'une implémentation EJB 3.0. BEA pour sa part avec Open JPA a ouvert une partie de son API de persistance Kodo basée sur l'API de persistance d'EJB 3.0 [http://www.bea.com/framework.jsp?CNT=pr01631.htm&FP=/content/news_events/press_releases/2006]. Quant aux autres serveurs d'applications, on ne devrait pas voir d'implémentations Java EE 5 avant plusieurs mois. A l'heure où les projets commencent tout juste à adopter J2EE 1.4, l'annonce de Java EE 5 et de EJB 3.0 est certes une bonne nouvelle, mais pour qui ? En attendant, les développeurs continuent d'utiliser Spring et Hibernate...