Anthony Patricio’s Blog

La fin de Spring Framework ? Oui, enfin peut-être

Posted in Actu / Anecdote by apatricio on mars 14, 2012

Depuis quelques semaines nous assistons à une déferlante d’articles annonçant le « retour » en grâce de Java EE, reprenant en force le terrain qu’il avait concédé à Spring. Spring n’a jamais été un concurrent de Java EE, plutôt un complément.

L’histoire se répète

Le cycle observé avec Struts se répète.
On ne va pas entrer dans des détails rébarbatifs mais globalement, concernant Struts

  • J2EE n’est pas efficient pour le web MVC
  • Une personne de talent va créer un framework en dehors de J2EE,
  • bien entendu ce framework ne ré invente pas la roue mais l’optimise
  • ça apporte tellement que le framework est massivement adopté
  • il devient « standard de fait »

A partir de ce moment, il y a 2 chemins possibles. Le premier est de contribuer à normer/spécifier pour Java EE ces avancées, à les intégrer dans le pack normé, en quelque sorte c’est apporter sa pierre à l’édifice. Le second consiste à se battre contre des moulins et s’obstiner à lutter contre la « norme » (on est dans le monde software hein, je parle pas de l’idéologie humaine de la norme à laquelle je n’adhère pas) ou pire tenter de la saboter et je pèse mes mots.

Se battre contre des moulins

D’une façon ou d’une autre, si l’idée brillante d’un cerveau n’est pas dans une spec, elle le sera tôt ou tard, grâce au cerveau à l’origine de l’idée ou non, telle quelle ou optimisée/évoluée/complétée. C’est inéluctable. La spec est bonne car elle ouvre la compétition à diverses implémentations. Car elle permet de ne pas ré inventer la roue. Elle est un repère. Elle résulte de débats impliquant diverses visions.

Plus important à mon sens, une spec est une garantie d’homogénéisation des compétences. Je m’explique. Le développeur qui a fait ses armes avec Hibernate 2 (standard de fait) est passé sans soucis à Hibernate 3 qui lui a ouvert les portes de manière assez transparente à JPA 1.0 puis JPA 2.0. C’est extrêmement intéressant et surtout pérenne en terme de gestion des compétences. Les projets ayant adopté Hibernate 2 en 2004, les SSII ayant misé sur les compétences Hibernate à cette même époque ne s’en rendent pas compte, mais ils ont fait un choix extrêmement profitable.

La personne qui a fait ses armes sur struts a du ré investir (lui ou son employeur) pour s’adapter aux nouvelles technos front web. C’est fâcheux car coûteux mais pourtant inévitable.

Que reste t-il à Spring ?

Spring s’est toujours posé en lévrier agile et pratique face au mammouth que sont qu’étaient les serveurs d’applications. Je dis « étaient » car avec GlassFish puis JBoss AS7 la donne a changé. J’ai développé une appli relativement complète et complexe sous JBoss AS 5 il y a quelques mois. J’avoue m’être vite lassé des temps de redémarrage du serveur. J’ai même très vite employé Arquillian pour mes tests unitaires. Mais maintenant? A quoi bon? JBoss AS7 démarre en 4 secondes avec mon appli déployée (moins de 2 vide). L’emprunte mémoire a été drastiquement réduite. Où est le mammouth? Qui plus est, si je souhaite toujours alléger mes tests j’utilise encore Arquillian et ShrinkWrap mais c’est un autre sujet.

Reste l’argument de dire qu’il y a trop de choses dans Java EE. Est-ce sérieux? Qui vous force à tout utiliser? Personne mais le jour où vous avez besoin d’un élément plus exotique, plus poussé, si Java EE vous le propose, vous l’avez! et il est prêt à s’intégrer dans votre application et votre environnement d’exécution le supportera. Et s’il n’existe pas? Et bien adoptez un framework hors Java EE, je parie un bras que les serveurs d’application sauront le digérer.

A ne pas vouloir intégrer son idée dans Java EE, on finit par réveiller la concurrence. C’est ce qui est arrivé avec Seam qui est venu concurrencer Spring. Seam n’a jamais été une copie de Spring mais permet aussi la conception orientée composants, l’injection des composants, s’appuie de suite sur les annotations (là où Spring les combat initialement) mais aussi l’apport de divers contextes. Les deux framework sont de très bons framework, assez différents en fait mais qui se chevauchent sur une petite région et c’est cette région qui méritait justement une spécification. La vraie grosse différence est que les gars de Seam, ceux de JBoss, sont en faveur des specs et ont ainsi proposé la spec CDI qui est un joli succès. Il faut bien avoir en tête ce que cela signifie. Lorsque l’on part d’un framework isolé, autonome, en dehors de Java EE, se battre pour une spec c’est:

  • exposer son framework « indépendant » à la concurrence de la spécification, c’est bien se tirer une balle dans le pied
  • faire un cadeau à la concurrence en lui permettant d’implémenter la spécification (pour JPA, Hibernate contre EclipseLink par exemple)

Mort? Enfin peut-être, pas si vite coco

Tout ceci semble donc annoncer la mort lente de Spring. Ce n’est pas de violence donc je fais preuve ici mais bien d’objectivité. Je ne pense pas que ma vision soit biaisée par le fait que je bosse pour JBoss, n’en déplaise à mes contradicteurs. Si je devais retrouver un poste plus indépendant de décideur technique, JBoss AS7 s’imposerait car sérieux, rapide, robuste, intégrant beaucoup de ce qu’une entreprise peut avoir besoin pour développer un application. Il y a une petite chance que j’utilise Spring avec JBoss AS7 pour un temps, histoire de voir comment évolue la spec capable de le remplacer (et de faire plus) mais mon but ultime serait l’adoption de chaque spec sérieuse.

Cependant 3 conséquences pour 3 contextes distincts:

  • Les entreprises ayant investi sur Spring vont continuer de le faire jusqu’à ce que les compétences disponibles sur le marché des développeurs sur ces nouvelles specs atteignent en volume les compétences Spring. Ce n’est pas demain la veille mais ça arrivera! Sauf si Spring se ré invente et sort de son chapeau de nouveaux apports flagrants, ce qui n’est pas le cas actuellement. Je ne dis pas que Spring n’apporte rien de plus ou de différent, je dis que ce n’est pas suffisant pour parer le choix Java EE.
  • N’oublions pas le parc d’applis basées sur Spring actuellement en production, peut être pour une décennie voire plus. Il y a encore moult applications basées sur Struts qu’il faut maintenir mais l’on voit bien justement le problème du coût de maintenance de ces applis. Les profils qualifiés en struts ne sont plus si faciles à trouver. Le développeur qui sera motivé pour intervenir sur une appli Struts est une perle rare (ou maso).
  • Enfin se pose la question des nouveaux projets. Un décideur technique ne foncera jamais tête baissée sur une Spec (ou même un Framework) 1.0 et ce même si les exemples de bonnes spec 1.0 sont nombreux. Que choisiront-ils?

Au delà de cela il ne faut pas oublier ce que les gars de Spring ont apporté à Java, énorme respect pour eux ils sont fait avancer le Schmilblick.

Publicités
Tagged with: , , , , ,

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :