Antoine : Enfin non sans Yann Blazart, car il avait des obligations familiales qui l'obligeaient à rester à Paris, donc je suis venu le faire tout seul.
Antoine : Oui donc Antoine Sabot-Durand, je suis Senior Developper chez RedHat depuis 2 semaines, avant ça j'étais dans une SSII qui s'appelle Ippon Technologies, je suis architecte Java / Java EE et je navigue dans l'IT depuis 16 ans facile, même 17. Et j'ai quand même une spécialité autour de Java EE et de CDI.
Antoine : Donc Java SE c'est la plate-forme de base du langage, donc c'est toutes les librairies standards de collection, d'encryptage, d'I/O, etc... et la partie EE viens s'ajouter au-dessus, donc ce n'est pas quelque chose à côté c'est quelque chose qui vient s'ajouter à la partie SE et qui va rajouter des services d'entreprise. Donc des services haut niveau pour faire de la sécurité, pour faire du web, de l'injection de dépendance, pour faire de la messagerie d'entreprise (donc avec JMS notamment). Donc c'est une couche plus élevée et dédiée à faire de l'application d'entreprise. Le EE ça veut dire "Entreprise Edition".
Antoine : Alors il y a effectivement un certain nombre de nouvelles JSR, alors je vais essayer de pas les oublier. Il y a une nouvelle JSR qui s'occupe de traiter le format JSON (JSON-P), une JSR dédiée aux WebSockets, il y a une JSR qui a mon avis est assez intéressante mais pour l'instant pas trop documentée (il n'y a pas trop d'exemples) qui s'occupe de la concurrence, puisque jusqu'à cette version de Java EE, on n'avait pas le droit en Java EE d'utiliser les API de concurrence standards de Java pour faire du multi-tâches notamment, et on devait passer uniquement par les EJB. Cette nouvelle spec va permettre de le faire de manière plus fine et sans avoir recours forcément aux EJB. J'espère que je n'oublie pas une spec. Après il y a des évolutions majeures dans certaines specs existantes notamment JAX-RS, la spec qui s'occupe de faire du REST. La version 2 de JAX-RS donc qui sort avec EE7 intègre un framework client qui n'existait pas avant, donc on va pouvoir consommer du service REST et pas simplement l'exposer. Et également elle va proposer un certain nombre de fonctionnalités qui avant n'existaient que dans les implémentations (donc des fonctionnalités spécifiques), je pense notamment à tout ce qui est filtres en entrée ou en sortie sur des appels JAX-RS. Évolution aussi très importante et très très attendue qui a fait couler beaucoup d'encre sur la mailing-list, c'est la nouvelle version de JMS. Donc JMS 2 sort avec Java EE7 avec beaucoup beaucoup de simplifications dans l'écriture des services à exposer et à consommer. La version 1 de JMS qui était donc en cours jusqu'à Java EE6, elle datait, je vais pas dire de bêtise, de 2001 ou quelque chose comme ça, il y avait donc beaucoup beaucoup d'attentes autour de cette spécification et les attentes ont l'air d'être remplies, si le terme est exact, donc c'est une spec assez importante. Après il y a des évolutions mineures autour de CDI, la version 1.1 qui clarifie des points et ajoute des fonctionnalités, JPA 2.1 qui ajoute des aspects comme le support des procédures stockées, donc ça sera intéressant pour tout les utilisateurs y compris ceux qui font autre chose que du Java EE mais qui font du Java. Et puis voilà, il y a des specs qui n'ont pas pu être au rendez-vous, qui normalement auraient dû l'être donc c'est un peu dommage. Notamment il y a une spécification de cache, qui n'est pas dans Java EE7, qui sera dans Java EE8 pour des raisons qui sont pas très très claires pour l'instant. Voilà j'espère que je n'ai rien oublié mais en gros voilà ce que j'ai pu retenir de ça.
6. InfoQ: D'accord, beaucoup de nouveautés et d'évolutions.
Antoine : Pour être honnête il n'y a pas de grosse révolution, mais il y a quelque nouvelles specs. Pour moi la grosse révolution c'était Java EE6 parce qu'il y avait quand même la livraison d'une stack enfin totalement opérationnelle. EE7 va dans la bonne direction mais pour moi elle est un peu moins ambitieuse et je pense que beaucoup de temps a été perdu pendant le travail de création, ce qui est un peu dommage.
Antoine : C'est une bonne question, surtout quand on regarde ce qu'il s'est passé pour les versions antérieures. Alors aujourd'hui il y a un serveur qui tourne sous Java EE7, c'est l'implémentation de référence donc qui est le serveur GlassFish, la version 4 de GlassFish, qui est officiellement sortie hier alors qu'il était disponible depuis quelques jours. La bonne nouvelle c'est que les autres serveurs d'application ont l'air d'être sur de bons rails. Alors moi je prêche ma paroisse, je vais parler du serveur de Red Hat, donc le serveur JBoss Server qui maintenant s'appelle WildFly. La version 8 alpha 1 de WildFly est sortie il y a quelques semaines et donc c'est la première version, enfin pré-version, pour supporter Java EE7. Donc il y a pas mal d'itérations apparemment qui vont avoir lieu, l'objectif est de pouvoir livrer une version finale en novembre. Donc si on compare avec les versions de serveur supportant Java EE6, si ces délais sont tenus on est dans un délai d'à peu près 5 mois, 5-6 mois, comparés aux presque 15-18 mois pour sortir un serveur Java EE6, notamment pour RedHat. Donc si ils arrivent à tenir, c'est une amélioration conséquente, on va diviser le temps presque par trois.
Antoine : Par rapport aux langages, Java EE son objectif ce n'est pas de supporter d'autres langages. Par contre on peut utiliser d'autres langages de la JVM pour faire du Java EE. On peut par exemple utiliser Groovy pour faire des bean CDI ou des EJB si on a envie, donc ça permet de tirer parti des améliorations syntaxiques de Groovy et de certaines fonctionnalités. Après, l'objectif de Java EE c'est d'être sur du Java donc il n'y a pas de stratégie dirigée vers ces langages alternatifs. Tout ce que je peux en dire c'est que c'est bien qu'il y aie une offre variée et qu'on puisse faire des choses assez différentes. L'idée en fait (enfin je suis pas spécialiste sur ces langages qui sont à la mode comme Scala ou autres), ce que j'en ai compris c'est que ces langages ils vont intégrer dans leur noyau un certain nombre de patterns ou d'approches innovantes, Java EE ne va pas avoir cette approche. L'approche de design patterns ou choses de ce genre va être amenée par des spécifications, des frameworks annexes. Donc on a des approches un petit peu différentes, et les deux sont très intéressantes je trouve.
Antoine : Alors déjà on pourrait faire un débat important sur la notion de légèreté. La notion de légèreté effectivement, le terme a lieu d'être puisqu'il y a deux ou trois versions Java EE était effectivement une stack très lourde. Les serveurs d'application, on va dire la génération N-1, étaient assez lents donc on avait des temps de démarrage à vide qui pouvaient être de 45 secondes voir plus pour certaines grosses solutions, et puis on avait des spécifications assez... J'allais dire mal fichues, c'est peut-être pas le terme, mais en tout cas très lourdes et obligeant à faire des choses pas très propres dans les développements, je pense notamment aux versions 1 et 2 des EJB, qui à mon avis ont beaucoup beaucoup desservies Java EE mais qui ont également eu le mérite de faire naître des frameworks comme Spring, donc c'est bien ça a créé de la diversité. Mais en fait cette vision des choses elle devrait maintenant être corrigée puisqu'on a une stack qui est aujourd'hui très légère, qui donne des serveurs qui se lancent en 2-3 secondes, allez moins de 10 secondes, et qui en tout cas du point de vue par rapport à Spring, en termes d'empreinte mémoire ou de rapidité, est totalement comparable.
Alors la philosophie est très différente. D'un côté en gros je vais embarquer tout ce dont j'ai besoin dans mon application, et dans l'autre on est censé m'apporter tout à portée de main et je vais faire mon développement comme ça. Alors là il y a aussi un long débat sur est-ce que je dois avoir tout, est ce que je dois emporter toutes mes provisions dans mon appli ou est-ce que je fais comme au restaurant, je prend la carte et je choisis, ça c'est un autre débat. Il faut quand même voir que les serveurs d'application comme le serveur de RedHat, donc JBoss, comme GlassFish, comme TomEE - la version de Tomcat qui supporte Java EE, évoluent en termes d'architecture, ont une approche beaucoup plus modulaire qui permet notamment de faire évoluer des briques ou de substituer une brique fournie par le serveur par une brique embarquée par l'application. Donc aujourd'hui cette problématique elle commence à s'estomper, elle n'est pas encore totalement estompée mais elle commence à s'estomper. On a la possibilité aujourd'hui d'avoir le meilleur des deux mondes, c'est à dire de s'appuyer sur une stack testée, éprouvée en termes de mélanges on va dire, et puis si besoin est de dire "ah ben non cette brique là qui est fournie par le serveur elle est trop vieille, donc soit je la mets à jour sur le serveur, soit dans mon application j'en prend une autre et je désactive celle du serveur pour mon application".
Donc pour revenir à la question Java EE vs Spring, la réponse elle est de moins en moins sur un plan technique. Pourquoi? Parce qu'en fait les deux stacks sont très proches. Spring est né parce qu'à l'époque J2EE (ça s'appelait comme ça) était compliqué à utiliser, générait du code très lourd, très verbeux et on a voulu proposer une solution plus légère. Effectivement à ce moment là c'était nettement plus léger. Il y a eu un certain nombre de frameworks comme Spring, comme tout ce qui tourne autour des ORM, Hibernate et compagnie, qui ont eu un effet bénéfique sur l'organisme qui s'occupe des spécifications Java EE, le JCP, et ils ont revu leur copie, ils se sont inspirés de tous ces frameworks, pour proposer des approches différentes. Donc par exemple CDI, qui est la solution d'injection de dépendance qui est intégrée à Java EE, elle doit beaucoup à Spring, elle doit aussi beaucoup à Guice et également à JBoss Seam, c'est un mélange de tout ça, et elle apporte cette intégration et cette légèreté qu'on pourrait attendre. Donc techniquement aujourd'hui on a deux stacks qui sont très proches en terme de mode de fonctionnement, après le choix il va être plus sur des aspects annexes, plus politiques qu'autre chose.
Je ne vais pas non plus débattre des heures sur le sujet mais on va par exemple se dire, à tort ou à raison, que d'un côté on a une stack supportée majoritairement par un acteur côté Spring où on a VMWare, de l'autre on a une stack, avec tout les désavantages que ça peut avoir, mais l'avantage est quand même là, d'être supportée par beaucoup d'acteurs, donc des clients peuvent se dire la pérennité elle est plutôt de ce côté-là. Pour contrebalancer, côté Spring c'est vrai que comme le framework est là depuis longtemps, que les gens l'ont quand même beaucoup utilisé, il y a quand même une offre en termes de développeurs beaucoup plus importante. Donc on peut se dire je vais plutôt prendre Spring parce que ça va être plus facile de trouver des développeurs, ou alors mes développeurs sont déjà formés sur Spring donc je m'embarque pas avec JavaEE.
Donc le choix il n'est pas out-of-the-box, il n'est pas immédiat, il n'est pas universel. Moi je sais que quand j'étais encore à faire du conseil il y a des fois où je conseillais le client de plutôt faire du Spring, des fois où mon client me disait "moi je veux être sur du standard, je veux que mes applis elles tournent encore dans 10 ans, etc...", alors je suis pas sûr que le fait de prendre Java EE aujourd'hui fait que ça tournera encore dans 10 ans mais c'est aujourd'hui à mon sens ce qui donne le plus de pérennité possible à une application, donc là on a d'autres critères. Mais je pense que de toutes façons les deux stacks vont converger. Tout ce qui est dans Java EE s'est beaucoup inspiré de ces frameworks légers, et on voit que Spring petit à petit va se rapprocher notamment de CDI. On a déjà des extensions Spring, comme Spring Data, qui intègrent CDI. Spring Data propose des extensions CDI pour que les services soient consommés par CDI donc on voit qu'on a la convergence.
Qui est quasi inéluctable, par exemple dans Java EE7 on a cette nouvelle version de JSF (que j'ai oublié de mentionner tout à l'heure). La version 2 de JSF intègre quelque chose de nouveau qui s'appelle TaskFlow et qui est un framework inspiré de Spring WebFlow. Donc en gros c'est une partie de JSF dans laquelle on va, un peu comme dans un système de BPM, définir des écrans avec des étapes, des états, etc... Donc des flows, des sous-flows, et TaskFlow dans JSF2 dépend de CDI. TaskFlow, la spécification JSF 2 et cette partie, a été beaucoup influencée par Spring WebFlow. Je m'avance peut-être un peu mais il me semble que des gens de Spring WebFlow sont venus sur la spec. Spring WebFlow il n'y a pratiquement plus personne qui fait la maintenance. Je crois qu'il y a une ou deux personnes, mais ces gens là vont certainement être libérés à faire autre chose. Donc la stack Spring, quand elle va proposer des solutions basées sur JSF - ça c'est un autre débat si c'est bien d'utiliser JSF ou pas, mais en tout cas il y a des entreprises qui l'utilisent et qui vont continuer à l'utiliser - cette partie WebFlow va être abandonnée par Spring très probablement, au profit de TaskFlow. Et TaskFlow dépend de CDI, nécessite d'avoir des builds CDI donc immanquablement si ce que je dis s'avère être le chemin qui va être réalisé, on va devoir avoir une version de Spring qui implémente CDI, donc on va devoir avoir une convergence.
Et ce n'est pas une question de l'un est meilleur que l'autre, etc... Ce débat il est à mon avis totalement dépassé, on a une émulation, on a des cas où l'un est plus intéressant à prendre que l'autre et réciproquement et voilà, on fait ce choix à ce moment là.
A savoir également - et après je ferme ce long débat - qu'on a aujourd'hui la possibilité d'utiliser un certain nombre de spécifications de Java EE (je parle encore beaucoup de CDI mais c'est quand même une spécification assez importante parce que c'est un liant autour de toutes les autres) CDI aujourd'hui on peut le sortir de Java EE et on peut l'utiliser sur du Java SE, dans une application Swing ou une application SWT, un desktop, on peut l'utiliser sur un Tomcat, on peut l'utiliser... j'ai fait des démos où j'ai un conteneur CDI qui se lance dans Jetty. Donc CDI est moins riche en terme d'écosystème aujourd'hui que Spring, mais il y a des choses qui arrivent - je pense notamment au projet Deltaspike, qui vient ajouter dans CDI des fonctionnalités comme on a des modules dans Spring qui viennent rajouter des fonctionnalités métiers - donc on va avoir deux solutions un peu équivalentes, qui vont évidemment se concurrencer, moi aujourd'hui je serais bien en peine de dire y en a une qui est radicalement meilleure que l'autre, elles ont chacun leurs avantages et leurs inconvénients (qu'on ne va peut-être pas détailler ici parce que sinon on sera là encore demain). En plus comme je n'ai pas de personne pro-Spring à côté de moi, j'essaye de rester mesuré.
InfoQ : Très bien, et bien merci beaucoup Antoine d'avoir répondu à nos questions et à bientôt.
Antoine : Merci! Au revoir.