Par Antoine Sabot-Durand (Ippon Technologies) : Les rendez-vous manqués de Spring Srping : un standard de facto, mais des questions demeurent
Spring pas un standard officiel et alors ?
Aujourd'hui, Spring est un standard de facto. Des centaines de milliers de développeurs dans le monde utilisent cet excellent Framework avec beaucoup de succès. Pourquoi se soucier de sa standardisation ?
Le premier point de réponse est lié à l'historique de Spring : cet outil est né pour palier à un gros défaut dans le standard officiel et proposer une vraie solution de conteneur de composants léger. Dés lors que le standard est corrigé, la raison d'être de l'outil s'estompe et même si sa popularité et sa qualité en font toujours un choix de prédilection, il rentre en concurrence avec une solution officielle équivalente, là où il aurait pu être ce standard.
Le deuxième élément est lié à la gouvernance de Spring. Comme on l'a vu la stratégie de Vmware n'est pas très claire et aujourd'hui seule une demi douzaine de cerveaux géniaux contribuent réellement à ce framework. Tout cela apparaît plutôt fragile et à partir du moment ou une alternative plus universelle existe, il paraît raisonnable de s'y intéresser pour éviter d'être captif d'une société en l'occurrence, VmWare.
Si CDI reste lettre morte, Spring pourra rester leader dans le monde des conteneurs légers sous Java
En prenant le problème par l'autre bout, on peut s'interroger sur les raisons qui ont pu retenir Spring de prendre cette voie de la standardisation. Franchement, en dehors du boulot énorme que doit représenter l'animation d'une telle spécification, je ne vois que des points positifs : l'évincement d'une solution concurrente, le ralliement des personnes n'ayant pas choisi Spring et la réassurance des utilisateurs existants. Bien sûr en transformant Spring en spécification, la société prenait le risque de voir d'autres implémentations concurrentes apparaître, mais avec l'avance de l'équipe de Rod Johnson, Spring aurait gardé le lead sur cette technologie comme Hibernate reste l'implémentation de JPA la plus utilisée même si Eclipse link est l'implémentation de référence de JPA 2.0.
Quel avenir pour Spring ?
Bien sûr, il n'est pas question de prédire la fin de Spring. Le Framework est bien implanté et continu à remplir sa mission avec succès. Néanmoins, il est toujours mauvais signe quand un outil de ce genre n'est pas choisi parce qu'il constitue la meilleure solution mais parce que prendre une autre solution couterait trop cher en formation et en gestion du changement.
Quoiqu'il en soit Java EE 6 et CDI ont beaucoup de chemin à parcourir pour devenir populaire. L'hostilité d'un certain nombre de développeurs aux productions de Red Hat et l'inertie naturelle des organisations pour adopter de nouvelles technologies sont ses pires ennemis. Mais il est tout de même fort probable que cette spécification rencontre un beau succès, la taille de la communauté Seam en est la meilleure preuve.
Concernant Spring, si CDI parvient à convaincre et commence à prendre de l'ampleur, le framework de VMware risque d'avoir à s'aligner sur cette spécification pour en devenir une implémentation au risque de se marginaliser. Auquel cas, il perdrait une partie de son leadership et deviendrait suiveur sur une technologie dans laquelle il était l'un des premiers acteurs.
Si CDI reste lettre morte, Spring pourra poursuivre sereinement sa carrière de leader dans le monde des conteneurs légers sous Java. Mais le pari est très risqué et au vu du besoin d'avoir une pile de framework officiels sous Java, Vmware n'est pas du tout assuré de le gagner.