Quoi de neuf dans Java EE 6?

Cela fait désormais bientôt deux ans que Java EE 6 est sorti, et il semble tarder à s’imposer en tant que grand successeur de J2EE5. Les raisons principales semblent être le délai écoulé entre la publication des spécifications et leur implémentation par les principaux serveurs d’application (les modifications côté serveur d’application sont nombreuses et lourdes à mettre en place). Glassfish a joué les précurseurs, les autres ont quelque peu tardé, et il a fallu attendre une bonne année avant que la quasi totalité des serveurs d’application s’adaptent. De plus, il est de notoriété publique que les entreprises n’aiment pas prendre de risques et préfèrent en général s’accrocher aux technologies qu’elles connaissent avant que les nouvelles qu’on leur propose n’aient été éprouvées pendant plusieurs années. Nous n’avons donc pas encore fini de voir des applications basées sur des frameworks ayant fait leurs preuves tels que Struts, Spring, JSF (avec Seam)…

L’un des derniers en date à s’être quelque peu imposé est Seam2 dont le but principal était de combler les lacunes entre les EJB et JSF, les spécifications ayant laissé un grand vide entre les deux. Seam2 a apporté un certain nombre de concepts sur la table : bijection (injection et outjection), nouveaux contextes de persistance des objets JSF, annotations à la place de lourdes configurations XML. Ces idées, apportées par des experts renommés du monde Java (pour ne citer que quelques noms : Gavin King créateur d’Hibernate, Pete Muir, Dan Allen…) ont plus ou moins servi de base aux JSR pour la mise en place de Java EE 6.

Je vais faire mon possible pour vous en donner un bref aperçu, mais le domaine est très vaste, et une couverture exhaustive demanderait de très nombreux articles comme celui-ci.

Nouveautés

Librairies inclues

Les ajouts sont nombreux, pour ne citer que quelques une des librairies majeures :

• EJB 3.1
• JSF 2.0
• JPA 2.0
• EL 1.2

Pour des informations bien plus détaillées sur ces quelques spécifications et toutes celles qui composent Java EE 6, je vous conseille vivement de vous rendre sur le site d’Oracle qui pointe directement sur les détails de chacune et sur le texte complet des JSR sur le site du JCP.

Facelets

Facelets est désormais le langage de description de page préconisé pour JSF 2.0. Il vous permet de définir des templates de pages XHTML. Jusqu’à présent, le langage de description de page préconisé était JSP, mais les cycles de vie de JSP et JSF s’adaptaient mal ensemble, les tags JSP étant analysés dans l’ordre de la page, alors que l’ordre d’analyse de ceux de JSF est plus complexe. Vous pourrez alors définir des templates de page, passer des paramètres à ces templates, modifier le contenu de certains des blocs définis.

N’ayez crainte, le conteneur s’occupe de tout

L’un des principes premiers de simplification est de laisser le conteneur se charger d’un maximum de concepts : transactions, injections, lookup JNDI (encore plus que dans J2EE5)… Le développeur peut alors se concentrer sur l’aspect métier de son application, ce qui amène à du code plus concis, plus propre, plus haut niveau.

Contexts and Dependency Injection (JSR 299)

Cette JSR définit un ensemble de services basés sur les contextes que le conteneur Java EE doit fournir pour simplifier l’utilisation des EJB dans des applications web. CDI définit, outre les contextes usuels de Request, Session, le contexte Conversation, qui représente un ensemble de pages qui rentrent dans le cadre d’une transaction fonctionnelle et le contexte Dependent (par défaut). Ces deux contextes sont définis au moyen des annotations correspondantes : @ConversationScoped et @Dependent. L’avantage vient du fait qu’on n’est du coup pas obligés de tout stocker en session et d’y laisser des données inutiles trop longtemps. On peut aussi imbriquer de telles conversations (avec la gestion des transactions qui est gérée automatiquement).

Dependency Injection for Java (JSR 330)

L’injection de dépendance est une généralisation du point précédent, et une intégration des principes d’IoC de Spring dans les spécifications Java. Ce mécanisme permet, au moyen d’annotations d’injecter des POJOs dans d’autres POJOs, managed beans etc, simplement en utilisant l’annotation @Inject.

Bean Validation

Il vous est désormais possible d’effectuer vos validations métier dans la couche de votre choix. Toutes les couches s’appuieront alors sur ces informations pour valider les données. Vos données seront donc vérifiées à la fois côté client et côté serveur, sans avoir à écrire de code redondant. L’utilisation la plus simple et la plus courante consiste à définir les contraintes au moyen d’annotations sur les entités manipulées (@Length, @NotNull, @Pattern…).

Une version plus légère et moins lourde à coder

Profils

L’un des principaux reproches fait aux serveurs d’application est leur lourdeur. En effet, pour déployer une simple application web, le serveur d’application se doit d’implémenter pas loin de 30 spécifications. Pour résoudre ce problème, la spécification Java EE 6 définit la notion de profil. Un profil correspond à un sous-ensemble de spécifications que le serveur doit implémenter. La spécification en elle-même ne définit pour l’instant qu’un seul profil : le Web Profile (qui contient entre autre les EJB Lite, JPA, JTA et les principales spécifications pour les pages web JSF, JSP…), mais il y a fort à parier que d’autres voient le jour prochainement.

Embeddable Container

L’un des principaux problèmes avec les EJB venait des tests unitaires. En effet, les session-beans sont des composants gérés par le conteneur d’EJB. Lors de l’exécution de tests, nous étions donc obligés d’utiliser des moyens détournés (outils et librairies tierces, mocks, tweaks dans le code). Ce problème est désormais résolu avec la norme EJB 3.1 qui permet d’intégrer un conteneur d’EJB “Embeddable”. Celui-ci tournera alors dans la même JVM. L’injection, transaction, cycle de vie, vous seront désormais accessibles même depuis vos tests !

Pruning

Cette nouvelle mouture introduit la notion de pruning. Le procédé ressemble beaucoup à ce qui a été fait avec J2SE6 en supprimant des méthodes ou des classes qui avaient été notées “deprecated” dans les versions précédentes. Cela permet d’alléger le contenu à embarquer dans la JVM et d’épurer des librairies souvent chargées. Ainsi, les différents composants de la spécification peuvent être “pruned”, ce qui veut dire en définitive qu’ils ne seront plus supportés à la sortie de la version suivante de Java EE. Aucune partie n’a pour l’instant été enlevée, mais plusieurs librairies ont été “pruned” et le seront à la sortie de Java EE 7 :

• JAX-RPC (JSR 101), désormais remplacé par JAX-WS, bien plus simple
• JAXR (JSR 93), qui permet de manipuler des registres UDDI. Etant donné que cette fonctionnalité n’est que peu utilisée, elle deviendra indépendante du socle Java EE.
• Java EE Application Deployment (JSR 88), même cas que ci-dessus
• Java EE Management (JSR 77), idem
• EJB 2.x Entity Beans CMP (une partie de la JSR 318), trop lourd, remplacé par JPA

Il est donc vivement recommandé de ne plus utiliser ces JSR sous Java EE 6, si vous voulez que vos applications survivent à la montée de version sans changement.

Configuration par exception

Un autre point important en ce qui concerne la simplicité de développement est l’application systématique de la configuration par exception. Ce point s’avère vérifié dans de très nombreux cas, par exemple, prenons l’exemple de JPA :

@Entity
public class Utilisateur {
	@Id
	private Long id;
	private String nom;
	private List adresses;
}

Le simple fait d’annoter la classe Utilisateur avec @Entity la transforme en entité JPA. En tant que telle, elle se trouve reliée à une table et chaque type de donnée utilisé comme attribut est directement mappé avec des valeurs par défaut. Ainsi, côté base de donnée, cette classe sera liée à la table UTILISATEUR, sa propriété nom sera mappée à une colonne de type VARCHAR2 ayant le nom NOM et la liste d’adresses sera mappée par défaut dans une table d’association UTILISATEUR_ADRESSE qui pointe sur les identifiants de l’un utilisateur et d’une adresse. Vous n’avez alors plus qu’à spécifier ce qui change dans votre cas de l’utilisation par défaut pour adapter le mapping à vos besoins particuliers.

Le code s’en trouve beaucoup plus clair, il ne s’encombre plus de données répétitives. Ce concept a été appliqué à toutes les couches de Java EE 6.

Annotations pour la partie web/JSF

Vous en avez marre des gros fichiers XML à écrire afin de faire marcher JSF? Bienvenue dans le monde des annotations. Il vous suffit désormais d’annoter un bean @ManagedBean pour qu’il soit directement accessible en EL depuis vos pages JSF.

Il y aurait encore énormément à dire sur les changements apportés, il faudrait de nombreux livres pour tout couvrir. Pour ceux qui n’en ont pas eu assez, je conseille les livres suivants :

• Beginning Java EE 6 Platform with GlassFish 3 (From Novice to Professional) par Antonio Goncalves (un français) ou la version un brin plus récente en français Java EE6 et GlassFish 3. J’ai trouvé cet ouvrage intéressant, il aborde les principaux concepts mais se limite trop à mon sens au champ des EJB. La partie CDI par exemple, n’est qu’effleurée. Je conseille ce livre comme un point de départ pour avoir une bonne idée générale de la philosophie derrière cette nouvelle version.
• The Java EE 6 Tutorial: Basic Concepts et sa suite Advanced Topics à paraître en décembre, ou la version condensée des deux (en 900 pages) gratuite en ligne sur le site d’oracle : The Java EE 6 Tutorial. Il ne faut surtout pas se fier à la couverture! Celui-ci a été écrit par des membres d’Oracle et aborde beaucoup plus en détail la quasi totalité des points qui font partie de la spécification. Cependant, le niveau de lecture est plus élevé et le volume, en cumulant les deux livres est 3 fois plus important que celui du livre précédemment cité. Autant dire que c’est là un mastodonte redoutablement efficace mais assez indigeste. Je le conseille donc à ceux qui sont vraiment particulièrement motivés.