Il y a des présentations qui m’ont marqué : vraiment bonne, où vous avez l’impression de passer la tête par la fenêtre en roulant sur une route au bord de l’océan. D’autres présentations m’ont laissé des souvenirs mitigés et m’ont même attiré des commentaires du speaker (Gradle for ever). Et bien mardi soir au Paris JUG c’était une très bonne présentation. L’indicateur de qualité c’est le nombre de pages que je gratte sur mon bloc, la taille de mon sourire à la fin et l’applaudimètre des quelques 240 personnes dans la salle. Ce soir sur une échelle de 1 à 10 nous étions à 12. Suivez le guide.
L’objet de la présentation d’Emmanuel Bernard est limpide : « Les Standards : caca ou pas caca ?« . Avec un sujet décalé, exercice imposé par Antonio, il s’en est très bien sorti. Emmanuel pour ceux qui auraient été dans une grotte ces derniers mois, travaille chez JBoss RedHat, s’occupe du Podcast « Les CastCodeurs« , blog de temps en temps et trouve aussi le temps d’être membre du Java Community Process en participant à la spécification JPA 2.0 et en étant Spec Lead de la JSR-303 (Bean Validation). Avec tout cela, il trouve le temps de venir au Paris JUG, c’était bien sympa.
Le format de la présentation tout d’abord est original. Il a utilisé les services de Prezi.com (voir ici des exemples) ce qui a donné une présentation originale et animée. Sa présentation est en ligne à cette adresse si vous voulez vous en faire une idée.
Standard : caca ou pas caca ?
Regardons les standards dans le monde Java. Ce n’est pas une dette technique mais une dette d’amour pour certaines spécifications. La légende veut que les spécifications désignées par des comités d’experts soient lourdes et inadaptées au marché. A l’opposé, le monde de l’open-source est un univers merveilleux où tout se passe bien, les gens s’éclatent et s’entendent super bien pour faire de magnifiques logiciels. Et donc il y aurait une épaisseur en latex entre ces deux mondes (ça c’est moi qui le dit, pas Emmanuel).
Il est vrai que si l’on regarde certaines perles du Java Community Process comme les EJB 1.x, les Webs Services WS-* ou CORBA, pour ne citer que les plus connues, on peut parler de Caca avec un C majuscule. A contrario, il y a des spécifications qui dans le monde Java, nous font juste travailler chaque jour : JAX-RS, JTA pour les Transactions, JDBC pour les accès à la base, les Annotations ou (petit coup de pub) les Beans Validations. Quelque part, merci d’avoir spécifié il y a quelques années JTA ou JDBC : cela nous permet d’avancer et de ne plus se regarder le nombril pour accéder à une base de données. Retenez bien cette idée d’Emmanuel : les standards nous font avancer.
La standardisation en dehors du monde Java nous fait gagner du temps. HTTP ou TCP/IP : grâce à cela nous parlons de l’avenir et du Cloud Computing, et nous ne nous battons plus pour échanger des fichiers. Grâce aux standards. Prenez la JVM. Moi le premier je suis encore étonné que peu de gens soient au courant que la JVM c’est 30 langages différents (Java, Groovy, Scala, même PHP). Les gens pensent encore que Java est un langage… C’est mignon. Non c’est une communauté et c’est une plateforme. Le langage on s’en tape le coquillard, excusez du peu. La JVM est une idée piquée à d’autres langages, mais sa standardisation nous permet de ne pas nous prendre la tête lorsqu’un programme écrit sur Mac, testé sur Windows, est mis en production sur Solaris. C’est simplement la réalité du terrain aujourd’hui.
Alors l’OpenSource serait trop bon. Bien meilleur que les standards validés par des comités. Regardons un peu cela avec ce que nous utilisons aujourd’hui : Spring, Hibernate, DOM4J, Ant par exemple sont des projets open-sources que tout le monde utilise. Mais comme pour les standards (EJB 1.x et Corba) il y a aussi de belles perles comme Maven 1.x, Struts 1 ou CGLibs. La communauté open-source Java c’est 230 000 projets sur SourceForge.net : dans le lot il y a Hibernate, mais il y a aussi des machins fumants qu’il ne faut pas utiliser. Et parfois il est trop tard pour se rendre compte qu’un projet open-source pose de gros problèmes (GWT-Ext par exemple).
L’univers de la standardisation c’est Dallas d’après Emmanuel. Et vas-y que je me fache avec toi, et que je lance mon standard pour t’embêter, et que je ne vote pas pour ta spec, etc. Mais le monde de l’open-source : c’est pareil ! Emmanuel explique que c’est même encore plus compliqué que dans les comités de standardisations : faire passer une idée dans le monde open-source sur un projet, c’est parfois impossible. Un excellent développeur de base aura du mal à faire sa place dans un projet établi. Donc les 2 se valent. Emmanuel rappelle le phénomène « The ServerSide » il y a quelques années. C’est un peu la presse People du monde Java. Chacun est libre d’écrire son article et de le publier sur ce site. La modération est plutôt légère et cela entraîne parfois des débats passionnés mais pas passionnants, entre grosses têtes de notre communauté. Ecouter l’autre est dur, accepter son point de vue, encore plus. Les humains sont comme cela.
Emmanuel change de chapitre et attaque maintenant le versant Nord de l’Everest.
Java EE ce n’est pas JBoss Application Server ou GlassFish. Ceux qui comparent Spring à Java EE sont stupides. Il faut comparer des produits. Il faut donc comparer Glassfish à Spring dm Server. Emmanuel dit cela car un standard est bien mieux défini qu’un produit. En effet, il doit aller à fond dans les détails et doit donc tout spécifier. S’il reste une zone de flou, c’est un risque pour que chaque éditer interprète cela à sa façon. C’est aussi pour cela qu’il faut proposer un kit de validation (Technology Compatibility Kit).
Les standards peuvent aussi faire preuve d’innovation. C’est surtout finalement en terme d’aggrégation que les standards innovent, si l’on prend le cas de Java EE 6 et des 28 spécifications attachées. Mariage difficile mais pas impossible. Si les gens s’écoutent, c’est possible. Java EE 6 en est le meilleur exemple.
Arrive la phrase qu’il fallait retenir de la présentation :
« Le standard est défini pour passer à autre chose »
Que vous inspire cette phrase mes amis ? Je me dis juste à cet instant précis : dommage que Spring n’ait pas suivi quelques standards de Java EE 6, du coup ils vont mourir. C’est méchant non ? Mais si SpringSource se sécurisait en effectuant un effort pour que quelques modules de leur architecture respectent les standards ? Cela permettrait alors à Spring de passer à autre chose, et de continuer à dynamiter la communauté avec leur formidable énergie. Lorsque l’on regarde de très bons produits comme Spring Batch ou Spring Security, on se dit qu’il serait intéressant de pousser ces projets afin qu’ils deviennent des standards dans Java EE 7. Vous ne pensez pas ?
Car Java EE 6 c’est une standardisation entre autre de l’inversion de contrôle et de l’injection de dépendances : cela va tuer Spring en opposant une normalisation, reprise par les différents acteurs du marché. Un peu comme lorsque nous opposions X25 et TCP/IP. A un moment donné, le standard a bouffé son voisin. Je sais que c’est un peu exagéré, et que vous serez nombreux à commenter. J’essaye de voir avec vous si l’hypothèse suivante est plausible : en ne suivant pas les standards, SpringSource prend le risque qu’une partie de ses produits soient sur des niches un jour.
A contrario, et si Java EE 6 faisait un bide ? Est-ce que le crédit confiance est assez élevé pour que la communauté adopte Java EE 6 ? Après tout, avec un Tomcat, du Spring et de l’Hibernate, on couvre aujourd’hui les besoins des applications Web simples. C’est pour cette raison que Java EE 6 propose un container EJB léger, embarqué. A un moment donné on a envie de dire : enfin !
Les standards vus par le Développeur, le DSI et l’Editeur
Emmanuel nous propose maintenant de regarder les standards selon différents points de vue. Pour le développeur, un standard c’est une API validée, c’est donc un investissement intéressant s’il doit se former. C’est aussi le moyen d’ajouter une ligne sur son CV, et de se dire que Google est ton ami, lorsque tu seras bloqué sur un point délicat. Emmanuel évoque Rails et Ruby. Bien que ce soient de bons langages et de belles plateformes, la taille de la communauté n’est pas aussi importante que celle de Java.
Du point de vue du DSI, celui-ci doit gérer des groupes de développeurs. Il a besoin de repères, et de s’assurer qu’il peut trouver des compétences demandées pour développer ses logiciels. En prenant un choix plus large, il sécurise ses investissements. Par ailleurs, savoir que l’on cherche un développeur Java/J2EE aujourd’hui, un développeur Java EE 6 demain, permet de réduire les coûts et d’éviter de payer trop cher ce qui serait trop rare (développeurs, consultants, indépendants).
Les projets Open-Source sont de qualités inégales. Le DSI peut se poser la question de savoir s’il y a une société derrière, s’il peut avoir du support, si les développeurs sont aidés et s’il y a quelqu’un qui pilote les développements. Prenez Linux (je vais me faire pleins d’amis ce soir). Il y a tellement de gens qui veulent contribuer à ce projet, que finalement aujourd’hui il existe tout un tas de distributions, et que chacun veut tirer la couverture de son côté. Le DSI a été content de trouver sur son chemin un visage professionnel (là on pense un peu à RedHat) pour pouvoir taper dessus en cas de soucis, et surtout, sécuriser ses investissements. Certains projets open-source sont inquietants, comme MySQL, aidé par SUN, qui lui-même a été racheté par Oracle… Oracle affirme qu’ils garderont MySQL, mais j’attends de voir avant d’y croire.
Enfin Emmanuel passe au point de vue des Editeurs de logiciels. Il y a plusieurs approches, chaque éditeur a une politique différente. Ils peuvent
– Réutilise les standards
– Implémente les standards
– Innover et défini de nouveaux standards.
Certains éditeurs ne veulent pas des standards. Cela les protège, en ayant « de l’innovation ». Quelque part, refuser d’utiliser des standards comme Spring ou Hibernate, c’est complètement has-been dans le monde Java. C’est mon opinion, pas ce que dit Emmanuel.
Il passe rapidement ceux qui ignorent les standards afin de s’attacher aux suiveurs, ceux qui reprennent les standards sans réellement innover. Spring / les frameworks Webs / Hibernate : on se met par dessus les standards (jdbc pour hibernate) et on les réutilise sans trop forcer. Les frameworks Webs : on utilise JSP et Servlets mais on met un peu de rouge à lèvre pour vous exciter : Tapestry / Wicket. Ces projets open-source ont une raison d’exister tant que le standard n’existe pas. Hibernate aujourd’hui est masqué par JPA avec son implémentation de référence qui est Eclipse TopLink (Oracle a offert TopLink à la communauté Eclipse).
Il y a ensuite les éditeurs qui innovent et implémentent les standards. JBoss a débuté en proposant une implémentation open-source de J2EE, ce qui en a fait son succès. Les éditeurs s’assurent une part du gâteau en implémentant un standard, afin de partager les retombées marketings et aussi afin de suivre les propositions normalisées.
Enfin il y a les éditeurs qui innovent et tentent de définir les standards. C’est beaucoup plus cher, beaucoup plus risqué. L’objectif est de s’attaquer à un monopole, et l’exercice consiste à synchroniser son énergie pour sortir un standard, afin d’attaquer un monopole sur le marché. Est-ce qu’Emmanuel pense au framework Spring à cet instant ?
Quoiqu’il en soit, pour l’éditeur le fait que son projet devienne un jour un standard le force à être encore meilleur. Hibernate n’étant plus le seul sur la place, normalisé par JPA2, il faut maintenant proposer d’autres innovations.
Et l’open-source ? Il y a des standards de fait après tout
Prenons le framework Spring, pour moi c’est un standard de fait. Les coûts de marketing aussi sont réduits. Puisque vous pouvez tester librement, c’est vous qui en faite la publicité. Concernant l’assurance qualité (QA) les projets open-sources sont très testés et corrigés aussi rapidement. Un projet open-source qui suit un standard normalisé, c’est certainement le duo gagnant je pense.
En conclusion
Pour terminer, Emmanuel explique qu’un bon standard doit être stable, extensible, ouvert sur le futur et surtout adopté par la communauté. L’objectif de Java EE 6 est de proposer un socle normalisé, afin que maintenant la communauté mette son énergie sur de nouveaux problèmes. Et là, mesdames et messieurs, il a raison. Bon sang quel temps perdu pendant 3 ans, nous devons maintenant passer à autre chose, et commencer à réfléchir à des serveurs de 4ème génération.
Bon, Emmanuel, tu reviens quand au Paris JUG ?
Je ne comprends pas trop ces pseudo conflits entre JEE6/Spring ou glassfish/DM server, etc… c’est clair qu’un standard c’est mieux, surtout quand il émerge du vécu terrain et pas d’une tour de crystal.
Le standard permet aussi de casser un « monopole », de permettre à de nouveaux entrants de tenter leur chance.
Quand aux produits, cela dépend de pleins de choses: prix, besoin, support, etc…
Maintenant faut-il vraiment choisir son camps de manière aussi tranchée?
En pratique je ne pense pas. Je travaille en ce moment sur une application en Java (pour un client dont il ne faut pas dire le nom, mais qui est tout simplement énorme). On utilise Spring, Tomcat, on fait du JPA, du JSF (avec Spring-Faces / Spring Web Flow / RichFaces), on y a aussi collé les bean validator d’Emmanuel, bref, on a fait notre shopping Spring/JEE. On compte bien évidemment passer à Spring 3 dès que ce sera prod-ready, à JPA2, JSF2, etc… bref, c’est l’harmonie Spring/JEE et nous sommes plutôt contents du résultat.
Dans une phase ultérieure nous convergerons peut-être vers du pur JEE6, ou autre chose qui sait, mais pour le moment ce n’est pas d’actualité.
« Les frameworks Webs : on utilise JSP et Servlets mais on met un peu de rouge à lèvre pour vous exciter : Tapestry / Wicket. Ces projets open-source ont une raison d’exister tant que le standard n’existe pas. »
Les frameworks webs ont deux caractéristiques particulières. Premio, ils ont été le théâtre d’implémentations de référence qui n’ont pas forcément convaincu. Servlet/sp et les taglibs a vite été supplanté par Struts. Et Jsf est venu après la bataille et n’a pas remporté le morceau, à cause de problèmes à jsf même, mais aussi à cause de l’émergence d’Ajax, qui n’avait pas été pensé dans jsf et qui a redistribué les cartes….
Donc, amha, Tapestry, Wicket et tout ça ne sont pas venu pour faire joli mais plutôt pour combler un vrai vide. Lors de la constitution des groupes pour spécifier jsf2, il était fortement question que M. Tapestry, Howard Lewis Ship, soit de ceux qui écriraient les specs. En fait les frameworks webs existaient tant qu’un bon standard ne s’était pas imposé (ce qui revient +/- à ce que tu dis, c’est vrai 🙂 ).
Deuxième spécificité des frameworks webs, ils sont à la charnière entre deux mondes, deux standards : le côté serveur et le côté client (html, xhtml, css). Le fait de devoir aussi faire avec la technologie client complique sérieusement une spécification. Pour preuve, jsf avait pris le pli de carrément dénier le html, de dire que l’on avait plus besoin de ce langage. (c’est un point que je n’ai d’ailleurs pas bien comris dans la présentation faite au parisjug sur jsf, ceux qui l’ont montré l’ont utilisé comme un langage de tempalte, complètement intégré à du html, alors qu’à la base les tags jsf étaient censé remplacer complètement le html, pas compris, si quelqu’un peut m’expliquer?) Quand jsp (mais aussi wicket, gwt…) avait pris le pari de s’intégrer au html ou de le manipuler.
On verra si jsf2 marche. Ce serait la première standardisation de la couche de présentation qui « marcherait », qui deviendrait un vrai standard – et non pas un truc contesté. A priori, vu que jsf a (lui aussi) fait son marché dans ce qui était devenu indispensable dans l’utilisation de jsf1 . A savoir jsf1+facelets+rich faces et – le faces-config … Admettons, que je ne crois pas qu’un système de balisages qui génère du html soit le plus amène pour faire un site web, mais pour un une appli web ça devrait passer.
La question est donc : comment jsf2 va réagir à la vague html5 de cette année (déjà assez forte) et de l’an prochain?
J’ai posté mon point de vue sur le blog du LyonJUG ;-). En résumé, j’y explique pourquoi un standard comme JavaEE est indispensable dans la compétition avec Microsoft .NET.
Merci pour cet excellent billet. J’avais malheureusement été contraint de partir sans pouvoir assister à la présentation.
Avec ce billet et les slides d’Emmanuel, j’ai l’impression d’y être 😉