{"id":457,"date":"2011-10-13T21:58:45","date_gmt":"2011-10-13T19:58:45","guid":{"rendered":"http:\/\/blog.fabianpiau.com\/?p=457"},"modified":"2022-01-01T16:14:27","modified_gmt":"2022-01-01T16:14:27","slug":"java-ee-cdi-vs-spring","status":"publish","type":"post","link":"https:\/\/blog.fabianpiau.com\/fr\/2011\/10\/13\/java-ee-cdi-vs-spring\/","title":{"rendered":"Java EE & CDI vs. Spring"},"content":{"rendered":"

 <\/span>English version available<\/strong><\/a><\/p>\n

Mercredi soir au JUG<\/a> nantais, nous avons pu assister \u00e0 la pr\u00e9sentation \u00ab\u00a0Stateful is beautiful\u00a0\u00bb d’Antoine Sabot-Durand. <\/p>\n


<\/p>\n

Expert en Java EE depuis plusieurs ann\u00e9es, Antoine nous a donn\u00e9 sa vision sur le paysage Java actuel, en particulier sur Java EE<\/a> (Enterprise Edition) et l’alternative Spring<\/a>.<\/p>\n


<\/p>\n

Spring est un conteneur dit l\u00e9ger qui permet d’obtenir une infrastructure similaire \u00e0 celle d’un serveur d\u2019application Java EE plus lourd. Si le premier ne connait que les beans stateless, le second connait aussi les beans stateful.<\/p>\n

L’exemple d’un site e-commerce est souvent choisi pour expliquer concr\u00e8tement ces deux notions.
\nLe panier sera repr\u00e9sent\u00e9 par un bean stateful dans le code. Son \u00e9tat est conserv\u00e9 pendant une certaine dur\u00e9e. Cela commence quand l’utilisateur ajoute un produit et prend fin lorsqu’il saisit son num\u00e9ro de carte bancaire pour payer. L’\u00e9tat stateless est suffisant pour la consultation du catalogue de produits. Pour afficher une fiche produit, on ne se pr\u00e9occupe pas des produits que l’utilisateur aura consult\u00e9 pr\u00e9c\u00e9demment. Le produit sera repr\u00e9sent\u00e9 par un bean stateless.<\/p>\n


<\/p>\n

\"Java       <\/p>\n

Antoine a \u00e9galement pass\u00e9 en revue les id\u00e9es re\u00e7ues sur Java EE. Ces id\u00e9es d\u00e9coulent pour la plupart de son historique et continuent de le poursuivre. A l’\u00e9poque de J2EE (comprenez Java EE 4 et inf\u00e9rieur – les versions sorties jusqu’en 2003), la sp\u00e9cification EJB 1.X – 2.1 incluse a essuy\u00e9 de nombreuses critiques de la part de la communaut\u00e9 Java. Tr\u00e8s lourde \u00e0 mettre en oeuvre du fait de sa complexit\u00e9 et rendant vite votre code tr\u00e8s difficilement testable, cette plateforme Java d\u00e9di\u00e9e Entreprise n’a pas convaincu…<\/p>\n

Ce manque a m\u00eame donn\u00e9 naissance au d\u00e9veloppement de solutions alternatives dans le monde Open Source, tels que Spring et Hibernate.<\/p>\n


<\/p>\n

Depuis, la plateforme (renomm\u00e9e Java EE) a \u00e9volu\u00e9 et a \u00e9t\u00e9 simplifi\u00e9e, la nouvelle sp\u00e9cification EJB 3.X incluse est devenue plus l\u00e9g\u00e8re se rapprochant ainsi de ses concurrents. Cela est particuli\u00e8rement vrai pour la derni\u00e8re version Java EE 6 sortie fin 2009. En effet, celle-ci inclut CDI<\/a> (Contexts and Dependency Injection), le standard qu’il lui manquait pour concurrencer s\u00e9rieusement Spring. Elle inclut \u00e9galement la notion de \u00ab\u00a0profile\u00a0\u00bb, permettant \u00e0 Java EE de se sp\u00e9cialiser. Dans les grandes lignes, on ne prend que les composants dont on a besoin. Pour les tests d’int\u00e9gration dans le conteneur, Antoine nous a conseill\u00e9 d’utiliser l’outil Arquillian<\/a>.<\/p>\n


<\/p>\n

       \"Logo<\/p>\n

Spring a fait le choix de ne pas impl\u00e9menter le nouveau standard CDI. Pourquoi? La r\u00e9ponse n’est pas si simple. Peut-\u00eatre qu’impl\u00e9menter ce nouveau standard allait \u00eatre impactant sur le code existant et risquait de mettre un frein aux \u00e9volutions du framework. En m\u00eame temps, fort de son nombre d’utilisateurs, peut-\u00eatre que SpringSource a d\u00e9cid\u00e9 de continuer son d\u00e9veloppement parall\u00e8le en esp\u00e9rant un jour d\u00e9tr\u00f4ner d\u00e9finitivement CDI. En g\u00e9n\u00e9ral, les entreprises sont plut\u00f4t frileuses lorsqu’il s’agit de revoir leurs habitudes, connaissances et autres bonnes pratiques (utiliser CDI au lieu de Spring serait un investissement tr\u00e8s important). En m\u00eame temps, cela peut \u00eatre \u00e0 double tranchant si CDI se met \u00e0 d\u00e9coller dans les ann\u00e9es \u00e0 venir. Affaire \u00e0 suivre!
\nA noter : contrairement \u00e0 Spring, Hibernate impl\u00e9mente JPA pour la couche de persistance (qui est le standard Java EE) lui assurant une plus grande p\u00e9rennit\u00e9 pour l’avenir.<\/p>\n


<\/p>\n

Comme Antoine l’a rappel\u00e9 \u00e0 de nombreuses reprises, le but de sa pr\u00e9sentation n’est pas de d\u00e9nigrer Spring. Bien au contraire, il continue d’ailleurs de l’utiliser et pourrait difficilement s’en passer. Il a notamment fait la m\u00e9taphore du \u00ab\u00a0marteau dor\u00e9\u00a0\u00bb avec Spring que j’ai trouv\u00e9e plut\u00f4t int\u00e9ressante. Aujourd’hui, la majorit\u00e9 des d\u00e9veloppeurs Java ne se posent pas de questions lorsqu’ils veulent faire de l’injection de d\u00e9pendance et utilisent spontan\u00e9ment Spring (on a un clou, hop on prend notre marteau favori). Pourtant, il faudrait pouvoir poser ce marteau dor\u00e9 quelques temps et voir ce qui se fait autour. En fonction du projet, Spring n’est pas toujours le plus ad\u00e9quat.<\/p>\n


<\/p>\n

Aujourd’hui, le succ\u00e8s de Java EE reste globalement mitig\u00e9, les id\u00e9es re\u00e7ues ont la dent dure, Spring a encore de beaux jours devant lui. Combien de temps encore? Seul l’avenir nous le dira… En attendant, Antoine nous invite fortement \u00e0 essayer Java EE 6 pour se faire sa propre opinion. A la fin, nous avons eu le droit \u00e0 une d\u00e9monstration : un projet exemple en Java EE, cr\u00e9\u00e9 en quelques minutes \u00e0 partir d’un archetype Maven et exploitant les notions stateful et stateless.<\/p>\n


<\/p>\n

Pour en savoir davantage, je vous invite \u00e0 lire ces deux articles \u00e9crits par Antoine :<\/p>\n