Soirée réussie hier soir au Paris JUG (Paris Java User Group) avec 240 personnes, des gens qui sont restés dans le couloir ou assis par terre, une soirée animée avec un débat JEE 6 ou Spring 3, bref du lourd. Un merci à Tanguy Bayard qui a assuré la sono.
La soirée débute avec la musique de Rocky, animée par Nicolas de Loof du Breizh JUG. Antonio Goncalvès pour JEE6 et Michael Isvy pour Spring 3.0 montent sur scène. Le ton est donné. Allons-nous assister à un combat de coq ? Et bien pas du tout. Dès le départ les règles sont posées : ce soir nous allons comparer les 2 univers, presque les 2 communautés, et arriver à la conclusion que tout est complémentaire.
JEE6 sortira le 10 décembre prochain (demain). Spring 3.0 a un petit peu de retard mais devrait aussi sortir très bientôt. Antonio nous fait remonter dans le temps. Java EE a 10 ans. Il y a 10 ans, cette spécification était pilotée par 8 éditeurs et 0 personne de la communauté open-source. Il y a 10 ans, la spécification était décidée puis les implémentations servaient à essuyer les plâtres. Aujourd’hui la manière de spécifier un tel travail a changé. Java EE 6 et ses 28 spécifications propose une simplification avec pour la première fois du « Pruning ». Si vous vous posez la question JEE5 ou JEE6, ma réponse est très claire : prenez tout de suite JEE6. Pas de bullshit genre « on attend que la dernière version soit un peu validée… ». Java EE6 c’est la plateforme des années qui viennent.
En 2009 la spécification est pilotée par 15 sociétés, 10 individus et 1 université. Tout le monde ne vote pas cependant, comme le dira Antonio plus tard. Les spécifications aujourd’hui dans la plateforme Java EE 6 sont le fruit du travail de la communauté open-source. Prenez JCDI 1.0, qui était avant WebBeans, qui lui-même vient du travail sur JBoss Seam initié dès 2005. Prenez JPA bien entendu, fruit du travail d’Hibernate. D’ailleurs l’implémentation de référence de JPA2 c’est Eclipse Toplink.
Antonio montre quelques innovations de Java EE6, pour ceux qui n’auraient pas encore acheté son livre.
Je vous glisse une photo où l’on voit Michael Isvy avec un teeshirt Glassfish et Antonio avec un teeshirt « I love Spring ». Oui les Français sont des gars marrants qui dépassent les clivages et arrivent à parler ensemble, ce qu’ils font très bien pendant cette première heure.
Antonio rappelle que toutes les implémentations de référence de Java EE 6 sont open-sources. Très important. Cela permet aux éditeurs de travailler avec les mêmes briques techniques. Par exemple prenez le projet Mojarra qui est l’implémentation de référence (RI) de Java Server Faces 2.0 (JSF 2.0). Ce projet porté par SUN est utilisé par JBoss dans ses produits. Ou prenez Jersey JAX-RS (SUN) il est utilisé dans Oracle Weblogic, etc.
En conclusion je me dis que le standard Java EE 6 c’est aussi enfin une réunion de famille où les éditeurs vont utiliser les mêmes projets open-source dans leurs produits, grâce à la normalisation. Est-ce que cela ne veut pas dire que ce serait la fin de la bataille sur certains sujets comme les ORMs, l’inversion de contrôle, la persistence, la plateforme web orientée composants ? La spécification fixe une bonne fois pour toutes les règles, afin que chacun puisse en décliner son implémentation.
On reparlera des standards avec Emmanuel Bernard tout à l’heure. J’espère que vous me suivez dans mes explications.
Spring 3.0
Michael Isvy prend la parole à son tour, afin de nous présenter les dernières nouveautés de Spring 3. Tout d’abord, pour la première fois il faudra passer votre JVM de la version 1.4 à la version 5 au minimum afin de faire tourner Spring 3. Cela permet d’alléger le code et de réduire la dette technique. Je trouve cela cohérent, après tout Java 1.4 n’est plus supporté depuis quelques temps déjà, et il serait temps de se bouger un peu aussi.
Spring dans cette version propose le support des architectures REST avec des annotations particulières, la gestion de la config avec Java Config, un langage d’expression pour améliorer les possibilités de configuration et donc, un passage à Java 5 obligatoirement. Spring 3.0 c’est la simplification, et après la présentation j’ai aussi le sentiment suivant : voilà, on a un superbe moteur que la communauté a adopté. Maintenant on nettoie et on simplifie, on bosse afin d’ajouter quelques fonctions intéressantes, mais l’essentiel est là. Spring arrive à un plateau de maturité. C’est un framework comme le rappelle Michael, pas une spécification.
Alors Java EE 6 ou Spring 3.0 ?
Cette question est stupide. Les 2 mon capitaine. Je vous encourage à regarder les nouveautés de Java EE 6, qui est plus léger et modulaire qu’avant. Les avantages de Java EE 6 c’est que nous parlons tout d’abord d’une norme, avec du code portable. Oui ne criez pas au loup avec vos soucis de portage qui marchent pas… moi le premier j’attends de voir pour y croire. Java EE 6 c’est plusieurs compagnies qui travaillent de concert pour proposer à la communauté des implémentations de références qui sont toutes open-source, chose que j’ignorais. Contrairement à notre vieux pote J2ee 1.4, il y a dès demain des implémentations qui tournent, et qui sont validées depuis des mois par la communauté. Prenez Glassfish v3, qui devrait être là autour de la mi-décembre, nous avons un serveur d’application qui implémente les spécifications de Java EE 6 prêt pour vos développements et vos mises en production.
Les critiques de Java EE 6 : oui il sera difficile d’étendre le spectre couvert par Java EE 6 ou de faire évoluer une des spécifications à l’intérieur des specs. Ce sera je pense, le point le plus délicat à gérer. Tous les JCPs n’ont pas de liste de diffustions publiques. Il y a donc des discussons de corridor entre éditeurs, où même Antonio n’a pas de droit de regards. Enfin une spécification de 28 spécifications a besoin du support de la communauté pour marcher, et là tout est à faire.
Concernant Spring 3.0, Michael Isvy passe aussi en revue les forces et les faiblesses de Spring 3.0. Tout d’abord Spring marche sur tout type d’environnement et sur la plupart des JVMs. Par rapport à Java EE, Spring ne propose pas que des annotations. 50% des utilisateurs de Spring préfèrent le format XML pour la configuration. Dans ma tête je me dis que pour ce qui est des EJB 3.1, il reste possible de faire du XML si vous le voulez. C’est vous qui voyez comme dirait Laspalès.
Les points faibles de Spring aujourd’hui : clairement, le gros soucis c’est que le coeur du Framework repose sur 5 personnes, employées chez SpringSource, qui portent le framework. C’est un risque opérationnel assez fort, où tous les oeufs sont dans le même panier. Certes ce sont des gens très forts et très intelligents. Mais ils ne vont pas faire « que » du Spring toute leur vie. Il existe aussi qu’une seule implémentation de Spring, puisque ce n’est pas une norme.
Là où Spring continue à jouer le rôle de locomotive dans l’univers Java EE, c’est aussi grâce à sa capacité à innover. La programmation par aspect, la gestion de la sécurité, le moteur de Batches, la gestion des exceptions… il reste encore pas mal d’idées intéressantes que Spring pourrait reverser à la communauté.
Mon analyse en carton qui vaut ce qu’elle vaut
Est-ce Spring n’aurait pas dû sauter dans le train Java EE 6 ? Prenez Hibernate par exemple : JBoss RedHat a reversé ses efforts à la communauté, en permettant à des personnes comme Emmanuel Bernard de contribuer aux spécifications, en finançant son travail au sein de l’expert group sur Beans Validation (JSR-303). JBoss RedHat s’est associé avec Oracle, SUN et IBM afin de ramer dans le même sens, ce qui permet aujourd’hui de bénéficier des retombées marketings de Java EE 6 à peu de frais. Ce qui permet de signer chez des grands comptes où le DSI préfère prendre un standard…
Si Spring était devenue une implémentation de référence de l’inversion de contrôle par exemple, cela aurait certainement offert à la communauté le meilleur framework sur ce sujet. Cela ne s’est pas fait car il y a des hommes. Des gens intelligents qu’il faut coordonner. Prenez 10 bonhommes avec un égo et une forte personnalité… difficile à gérer.
Regardons aussi la partie financière, car c’est le nerf de la guerre. SpringSource à ma connaissance ne gagne pas beaucoup d’argent avec le framework en lui-même. Qui va acheter du support pour le chassis de sa voiture ? Personne. Tu signes avec le concessionnaire, pas avec l’industriel qui a construit ta voiture. Les pépites chez SpringSource/VMWare s’appellent Groovy et Hyperic. Ne cherchez pas plus loin, pour l’instant il y a aussi CloudFoundry, mais le coeur du framework ne fait pas vivre SpringSource. Oui il y a les formations, mais ce n’est pas du revenu récurrent comme une licence ou du support. Du côté des produits packagées et certifiés, SpringSource fait un gros effort pour proposer des solutions certifiées aux Entreprises. Spring tc Server et les outils d’administrations par exemple, mais est-ce que cela porte ses fruits ?
Conclusion de la première partie
Un bon démarrage, avec un peu trop de Java EE6 par rapport à Spring, avec aussi l’envie de défendre celui qui est entrain de se faire bousculer par les copains, avec aussi une envie de dire à un moment que pour l’instant, Java EE 6 doit faire ses preuves pour passer dans la classe supérieure. Mais avec aussi une envie de vous dire : allez voir le film, allez voir ce que propose Java EE 6. C’est intéressant.
Je vais juste dormir, car il est un peu 04h20 du matin, et je me réserve quelques neurones pour vous parler de la présentation d’Emmanuel Bernard, qui était juste… énorme (j’en rajoute un peu car je veux un teeshirt JBoss Redhat).
A+
TinyURL de cet article si vous voulez en faire une publicité monstrueuse sur Twitter : http://tinyurl.com/yhhqf3j
Je ne trouve pas que « tout est complémentaire » et je ne pense pas que ce soit la conclusion d’Antonio et Michael. Il y a beaucoup de recouvrements de fonctionnalités avec des approches subtilement différentes.
« (Spring) C’est un framework comme le rappelle Michael, pas une spécification. »
Tiens c’est bizarre je croyais que c’était un conteneur léger! 😉
Sinon, c’est Metro qui est dans WebLogic, pas (encore!) Jersey
Petite réponse à Monsieur Laspales : j’ai sûrement parlé un peu trop vite. Je ne parlais pas de support XML en général mais de support XML avec des fonctionnalités sympas et travaillées.
En Spring tu as les p:namespaces, l’héritage entre beans, la possibilité de faire des namespaces pour déclarer moins de beans et des dizaines d’autres choses. En EJB 3 le support XML est minimaliste parce qu’on encourage tout le monde à passer aux annotations.
Donc ce petit commentaire, c’était juste pour dire que je n’étais pas d’accord avec l’équation « XML == verbeux ».
Le XML, c’est comme les chasseurs, il y a le bon et le mauvais…
Bonjour,
Savez vous si le JUG a été enregistré en vidéo et serait dispo sur un site ?
Merci
Gilles S
Oui, il a été enregistré et il sera dispo ici :
http://beta.parleys.com/#st=4&id=56644
Bonjour,
C’est le premier commentaire que je poste sur le blog, que je viens lire religieusement tous les matins. Je commencerai donc par un grand merci pour tous ces très bon articles.
Sinon concernant ce billet, je pense que l’on met trop souvent Spring et JEE en opposition alors que le couple fonctionne parfaitement. Prenons l’exemple de l’AOP Spring apporte vraiment quelque chose d’ inintéressant. Alors effectivement certaine parti sont redondante mais il faut juste utiliser le meilleur des deux pour en extraire toute la saveur 🙂
Après pour les évolutions je suis entrain de regarder ce qui se fait dans le JEE6 et je n’ai pas prie le temps de regarder du coté de Spring 3 peut être que je changerais d’avis après
@ plus
Fabien