Accueil Nos publications Blog [Devoxx FR 2012] – Spring est mort. Vive Spring!

[Devoxx FR 2012] – Spring est mort. Vive Spring!

Gildas Cuisinier, fervent défenseur de Spring, nous a présenté les points qui font que Spring a encore du temps devant lui avant de mourir. En effet, l’arrivée de JEE6 et CDI annonce la mort de Spring et plus particulièrement Spring Framework.

L’orateur nous a exposé l’histoire de Spring afin de nous placer dans le contexte et nous convaincre que Spring a encore de beaux jours devant lui avant de mourir.

Débuts de Spring Framework

Spring Framework a été créé dans le but de répondre à une problématique récurrente dans le monde Java: comment gérer au mieux les injections de dépendances pour que ce soit aussi simple à l’utilisation qu’en tests tout en étant léger, opensource.

La première version s’appuyait sur une base XML très prononcée. Au fur et à mesure de l’utilisation de Spring dans les applications, la base forte composée d’XML a commencé à chatouiller un peu les développeurs. Le fichier applicationContext.xml prenait de plus en plus de place et la maintenance n’était plus aussi simple qu’avant.

Une première vague d’évolution a amené la possibilité d’importer des fragments de fichier de configuration. Cela a permis de rendre le applicationContext.xml moins lourd, de découper le fichier par thème de configuration. Il subsistait encore des problèmes avec la verbosité et la complexité à configurer certaines briques de l’architecture comme, par exemple “ACEGI Security” dont la configuration au sein de Spring n’était pas ce qu’il se faisait de plus lisible.

Vint alors les namespaces qui ont arrangé ce souci de clarté et de concision. Cependant, cela restait du XML et pouvait contrarier certains développeurs qui ont pu découvrir entre temps la formidable invention des annotations.

Spring a cherché à évoluer en ce sens en proposant des annotations comme @Component, @Autowired, etc. Mais pour que cela fonctionne, il fallait tout de même fournir une ligne de xml activant un scan de package.

<context:component-scan base-package=”...” />

L’arrivée de JEE6 et le spectre de la faucheuse.

JEE6 arrive en 2009 avec ce qui pourrait être la mort annoncée de Spring Framework. En effet, JEE6 apporte CDI dans son pack de nouveautés. CDI est issu de la JSR-299. Une référence ne parlant pas forcément aux non addicts, cette JSR-299 a pour titre : “Contexts and Dependency Injection for the JavaTM EE platform”.

Wahou! Coup de massue pour Spring Framework qui fait ce travail depuis 2003! Beaucoup annonce la fin de Spring à cause de l’arrivée de ce standard. Cependant, on en oublierait presque qu’une bonne partie des applications tournant en entreprise sont sur des serveurs ne supportant pas encore ce JEE6 et que si ces entreprises veulent passer en JEE6, alors cela impliquera des dépenses, des corrections de bugs sur les applications existantes qui pourraient survenir à la suite du passage vers JEE6, etc.

En effet, Spring Framework est déjà utilisé avec les infrastructures JEE5 et continuera de l’être. Peu de temps après la sortie de JEE6 (mai 2009), nous apprenons le rachat de Springsource par VMware ainsi qu’une évolution de Spring en version 3 avec l’annotation @Configuration qui permet de s’abstenir d’une partie de l’applicationContext.xml.

L’idée de rendre l’utilisation d’XML optionnelle dans la configuration de Spring et de pouvoir complètement la remplacer par des annotations a muri. La grappe XML suivante se substitue avec les annotations @Configuration (balise <beans/>) et @Bean (balise <bean/>)

<beans>
<bean ... />
<bean ... />
</beans>

Ce n’est cependant que dans la version 3.1 qu’ils arriveront à nous proposer de rendre complètement le XML optionnel.

 SpringFramework 3.1

Au menu, des annotations nouvelles comme les @Enable*, @Component-scan, @Profil pour des profils de configuration imposant les dépendances en fonction des environnements de développement-tests-préproduction-production par exemple, @Cacheable/CacheEvict pour une abstraction de cache (géré avec @EnableCaching des @Enable*).

SpringFramework 3.1 permet de tout avoir en annotation mais ne coupe pas le XML pour autant car le XML a pour avantage qu’une lecture du XML et des imports permet de cartographier l’application. Alors qu’avec les annotations, il faut ouvrir chaque classe pour voir son rôle et ses annotations. C’est une question de goûts et de couleurs.

 Mort ou pas mort ?

Spring en lui même n’est pas prêt de mourir car Spring, ce n’est pas juste SpringFramework, c’est tout un écosystème avec comme projets utilisés :

  • Spring Batch
  • Spring Framework
  • Spring Mobile
  • Spring Security
  • Spring Social
  • Spring Web Flow
  • Spring Web Services
  • et même Spring .NET

Cet ensemble de projets gravitants autour de Spring assure une certaine durée de vie à SpringFramework.

Même si JEE6 avec CDI est devenu le standard pour ce problème d’injection de dépendance, il est la norme et comme toute norme, cela demande du temps d’adaptation, du temps pour percer et s’implanter comme référence. Cela fait 2ans maintenant que JEE6 est arrivé mais d’après le sondage cyg.be/SpringJEE seulement 27% des plateformes en production utilisent JEE6 en ce moment contre 56% pour JEE1.5, 13% pour JEE1.4, les 4% restant ayant répondu “None” à la question.

Le temps d’adaptation cumulé, accompagné du coût de migration de JEE5 vers JEE6, laisse encore de beaux jours à SpringFramework dans le monde de Java Entreprise.