La première soirée du Paris JUG avait lieu comme chaque deuxième mardi du mois à l’ISEP, avec le sponsor de SUN Microsystems ce soir. Les 2 thèmes présentés : JEE6 par Antonio Goncalves et Glassfish v3 « Prelude » par Alexis Moussine-Pouchkine. Je vous le dis d’entrée : c’était une très bonne soirée. Sur une échelle Touilleur de 1 à 10, nous sommes pas loin du 8. On reste à 7 mais honnêtement, le contenu était très intéressant.
Absorbé par Devoxx j’ai zappé les présentations d’Antonio à la conférence Open Source Exchange organisée par Xebia, et à la présentation d’Alexis en décembre puisque j’étais encore en Belgique. C’est donc avec un œil neuf et affuté que j’ai écouté, noté et apprécié ce soir les présentations.
J’ai pris la parole au début afin de présenter 2 informations importantes : la création du Scrum User Group, sur le modèle du Paris Java User Group. Cela se passe sur le site http://www.frenchsug.org, et nous nous verrons tous j’espère le 19 mars à Paris afin d’assister à l’inauguration du SUG en présente de Jeff Sutherland. Je compte sur votre présence si Scrum vous intéresse !
Deuxième chose que j’ai proposé au JUG il y a quelques semaines : reprendre l’idée des tableaux blancs vue à Devoxx et proposer aux gens de voter pendant le buffet. Les deux thèmes proposés ce soir : « Quel serveur d’application est votre serveur favori ? » et « En dehors de Java, quel est le langage qui vous intéresse le plus ? ». Grâce à mon superbe iPhone je vous donnerai les résultats demain.
Antonio a donc commencé sa présentation afin de nous donner un état des lieux de JEE6 ainsi que les prochains sujets à venir. Tout d’abord, un peu d’historique. J2EE a maintenant 10 ans. En 1999 c’est la sortie de la spécification 1.2 avec déjà les servlets, les JSP et JMS. En Novembre 2003, sortie de la version 1.4 de Java. Oui cher lecteur, votre superbe serveur d’application se base sur une spécification qui a presque 6 ans ! En mai 2006 c’est la sortie de JEE5, avec déjà 23 spécifications. Enfin la prochaine étape en juin 2009 sera la sortie de JEE6, si tout va bien. Alexis pense que la sortie officielle se fera pour JavaOne 2009.
Le mot d’ordre pour JEE6 est :
– plus riche
– plus léger
– plus facile
JEE6 sera modulaire. Une version Lite (et pas light ?) sera proposée par exemple afin de donner aux développeurs uniquement ce dont il a besoin pour coder son application Web. Dans la version lite, si j’ai bien noté, pas de MDB, de RMI/IIOP, de Remote Interface, de Time Serice, de CMP/BMP… Bref comme dit Antonio, c’est la version Coca light.
L’effort de simplification vise à offrir un socle plus simple et plus prêt des cas d’usage que nous voyons au quotidien. Le Web profile est une spécification à part entière, avec Servlet 3.0, JSP 2.2, EL 1. et JSTL 1.2. Il est donc évident que quoique l’on puisse dire, JEE6 sera avant tout plus léger.
Antonio explique ensuite la notion de « pruned ». Certaines parties de la spéc (Entity Bean, JAX-RPC, JAX-R et JSR-88) seront marqué comme « pruned » ce qui correspond à un gros Deprecated. EN JEE7 ces modules disparaitront car ils ne sont plus utilisés aujourd’hui.
Ensuite nous avons voyagé dans la spécification JEE6. J’ai trouvé la présentation des Servlets 3.0 à la fois simple et efficace. Après avoir vu du code si clair et si mature, pourquoi aller chercher un framework d’injection alors que ce concept sera de facto dans JEE6 ? Quelques annotations comme @WebServlet ou @ServletFilter permettent au développeur de marquer son code Java, afin que celui-ci se comporte comme une servlet ou un filtre dans son application Web. La modularité et enfin le support d’un mode asynchrone ont achevé de convaincre le sceptique que j’étais en arrivant. J’ai été séduit par la clareté du code. J’avous que depuis 4 mois je ne suis pas tellement l’activité du côté JEE6. Antonio étant un membre du JCP sur JEE6, il est bien placé pour nous dire ce qu’il se passe derrière en coulisse. On y reviendra tout à l’heure.
La présentation sur JSF2.0 m’a permis de voir les efforts de simplification. @ManagedBean sera suffisant pour annoter un bean, le fichier faces-config.xml sera optionnel. JSF a viré les JSP et se base sur Facelet comme le confirme Alexis plus tard, autour d’une bière.
JEE6 introduit quelques nouveaux concepts comme l’annotation @Singleton qui permet de s’assurer que le conteneur d’application n’instancie qu’une seule fois une classe. Rien de révolutionnaire mais c’est géré par le conteneur.
Antonio enchaîne ensuite sur un souci vu et revu avec les EJB2.1 : comment ajouter des traitements asynchrones ? L’usage de la classe Thread n’est pas autorisé en EJB2.1. Pour palier cela il explique que les architectes ont fait appel à JMS afin d’introduire de l’asynchrone… Grave erreur.
JEE6 propose une annotation toute simple : @Asynchronous. Cette annotation est placée sur une méthode afin d’indiquer au conteneur d’application que son exécution doit être asynchrone. Ni plus, ni moins. Si vous devez ensuite récuperer le résultat de cette exécution, les Future
Du côté du packaging, l’EAR n’est plus obligatoire, vous pouvez packager votre application JEE6 dans un war. Nous continuons ensuite sur la présentation des portables JNDI. C’est très simple : les annotations permettent maintenant d’injecter automatiquement les références. Plus de narrow portable machin chose.
Pour les tests d’intégration, JEE6 propose aussi la notion de conteneur embarqué. Cela permettra par exemple d’effectuer des traitements type Batch processing. D’ailleurs le Time Service m’a semblé un remplaçant tout à fait acceptable pour retirer du code basé sur Quartz et me reposer sur un standard. La syntaxe à la cron permet de scheduler l’exécution périodique d’une méthode, et donc, d’effectuer des traitements sous la forme de batches. En voyant tout cela et en pensant à notre plate-forme de traitement chez mon client, j’ai eu le sentiment de voir aussi une révolution pour nous, développeur. Cette simplification va entraîner un sacré effort de votre part pour bien vous former à JEE6. Cela tombe bien, Antonio a annoncé qu’il va sortir une nouvelle version de son livre en français. D’ailleurs (et après j’arrête la pub) SUN organise le 5 février un événement à son centre de formation à Paris à côté de la Madeleine. Il y aura des livres à gagner pour les personnes présentes. Je vous redonnerai plus de détails, ou si quelqu’un de SUN me lit, qu’il ajoute dans les commentaires les détails sur cet événement.
Revenons à notre caviar. On sent un peu que la peinture n’est pas sèche, mais Antonio est transparent durant sa présentation. JPA 2.0 apporte encore quelques modifications, avec par exemple une annotation pour un meilleur support des collections (@ElementCollection). Par ailleurs j’ai noté que là où JPA 1.0 ne propose que le mode OPTIMISTIC LOCK, JPA 2.0 propose 5 modes différents de LOCK pour gérer finement la lecture des données transactionnelles. A suivre donc.
Du côté de REST, puisque c’est l’un des dadas du moment, la spécification JAX-RS 1.1 est sortie. Elle propose via des annotations un système qui permet d’annoter un bean afin de le transformer en ressource REST. A ce propos, après avoir vu la simplicité de JAX-RS, je me demande pourquoi Spring a eu l’idée de refaire sa propre implémentation de Rest… Même Jérome Louvel (framework RESTlet) offre un support de JAX-RS. Quel diable a piqué Spring pour qu’ils ne suivent pas le standard ?
En conclusion JEE6 est simple, riche, modulaire même si je n’ai pas parlé des profiles, standard (hé oui) et robuste avec 10 ans derrière nous.
Lors de la séance de question/réponse, Cyrille Leclerc de Xébia a mis le doigt là où il y a un gros point d’interogation : quid de Web Beans ? La réponse il fallait aller la chercher à 23h35 après une petite bière. J’étais assis à côté d’Alexis et d’Antonio après la présentation au Falstaff, un bar où nous nous retrouvons après le JUG. La question c’est ce qu’il va se passer le 9 février. Les personnes du JCP vont voter pour ou contre l’adoption de WebBeans. En cas de refus, un deuxième vote sera alors proposé. En cas de refus, WebBeans sera retiré du scope de JEE6, ce qui peut très bien arriver. A Devoxx les 2 présentations que j’ai vu m’ont inquieté, et m’ont donné le sentiment que WebBeans propose son modèle là où les EJB 3 se débrouillent très bien depuis 2 ans… C’est donc un sujet qui représente en ce moment un gros travail pour les personnes du JCP, afin de mettre à plat et de s’assurer que la spécification finale JEE6 sera conforme aux attentes de tout le monde.
Deuxième partie : Glassfish V3 « Prelude »
Alexis Moussine-Pouchkine est l’ambassadeur du projet Glassfish. Il fait le pont entre la communauté d’une part et le monde de l’entreprise d’autre part. Sa présentation porte sur la future version à sortir de Glassfish, le serveur d’application open-source de SUN.
En introduction, Alexis explique qu’il y a presque 10 ans, SUN a donné à la communauté open-source le serveur d’application Tomcat. Aujourd’hui, il est intéressant de voir que certains partenaires, comme SpringSource, s’investissent sur Tomcat afin d’offrir un support professionnel et une offre de service. Il faut mentionner « SpringSource tc Server » de SpringSource qui est un Tomcat avec des outils avancés de gestion et de diagnostiques, utilisés par les équipes de production.
La publicité a été supprimée après 20h30, je vais arrêter la pub pour Spring.
En octobre 2008, le projet Glassfish a annoncé la sortie de la version V3 « Prelude », en prélude de la sortie de la spécification JEE6. Je pense que si tout va bien, Glassfish V3 « VAS Y MON GARS C EST LA VERSION CERTIFIEE JEE6 » sortira cet été. Notez que pour le nom et la version on est pas tout à fait certain que SUN suive mon idée…
Alexis d’un subtil clic de souris (yeah! Mac Rulez!) nous montre ensuite un slide sur le nombre de visiteurs du site Glassfish.org (450 000 par mois) et du nombre d’affichage d’une page HTML lancée lorsque vous démarrez Glassfish via Netbeans, dans les 45 000. Dans un slide suivant on constate que Glassfish est beaucoup plus téléchargé que JBoss Application Server. Au final peu importe les downloads, Glassfish intéresse la communauté et représente en France aussi des projets majeurs comme les sites Internet de RTL, de Fun Radio et aussi SFR. Glassfish v2 est en production sur des sites Internet majeurs en France.
L’objectif de Glassfish V3 est de proposer un serveur d’app très léger. Cela ne veut pas dire forcément Tomcat, c’est surtout le souci du temps de démarrage. Une personne dans la soirée me confie qu’il a fait des tests avec la même application sur JBoss 5, Websphere 7 et Glassfish V3. JBoss demande 30 secondes pour démarrer, Websphère 7 demande 2 mn et Glassfish à peine 3 secondes…
Un serveur léger c’est donc un serveur qui démarre rapidement et qui ne chargera ensuite le reste de ses modules que lors de la première utilisation. Pour cela, Glassfish est basé sur un noyau OSGI (Apache Felix). Je note sur mon petit cahier qu’Alexis insiste sur un concept de Glassfish : pas d’OSGI pour le développeur final. Et je vais vous donner mon avis : je suis d’accord. Aujourd’hui il faut arrêter de raconter aux développeurs que les gens des équipes de production vont arrêter une « partie » de l’application… Avec le foutoire d’une application J2EE 1.4, je peux vous dire que les équipes de production se sont adaptés à ce système, et que les mises en production ne s’effectuent pas avec de l’OSGI. Je n’y crois pas pour l’instant. Je crois à OSGI pour simplifier la récupération des dépendances, comme le système de Spring qui est élégant. Je n’arrive pas à croire au machin qui relance une partie de mon application…
Pour continuer, Alexis explique ensuite que Glassfish V3 propose des modules afin de supporter par exempel Grails/Groovy ou encore JRuby/Rails. Et il insiste aujourd’hui sur les problèmes que rencontrent les développeurs Rails face à un Apache. Il explique que Glassfish est une réponse industrielle au problème du déploiement des applications Rails. Un seul process, un moteur de gestion des Threads et des entrées/sorties basé sur Grizzly, Glassfish enfonce Apache ou d’autres serveurs proposant le support de Rails.
Parmi l’offre de Prelude, la console d’administration m’a semblé simple et claire. A comparer à la console de Websphere. La première fois que j’ai utilisé Websphere 6.1, après avoir lu les éléments de la page d’administration j’avais oublié pourquoi je m’étais logué sur cette page… Pour avoir mal au crâne, y’a pas mieux.
Du côté de Glassfish on voit qu’un effort de simplification a été fait.
Glassfish c’est aussi et surtout l’Update Center. Ce système permet d’installer des modules supplémentaires dans Glassfish, comme la gestion des packages sur une distribution Linux. Très pratique pour Grails, Alexis explique que ce système permettra de mettre à jour son serveur Glassfish au fur et à mesure de la sortie des modules certifiés de JEE6.
Enfin un mot rapide sur la version « embedded » de Glassfish, elle permet de faire des tests unitaires mais aussi d’embarquer un serveur léger dans une application java web start… Cependant il n’y a pas de support d’OSGI.
Les démonstrations d’Alexis nous ont montré les concepts de rechargement à chaud de Glassfish ainsi que les temps de démarrage.
Tout d’abord le temps de démarrage. Souvenir pour moi : en juillet 2007 à Noisy-le-Grand, je travaille 2 semaines sur le portage vers WebSphere 6.1 de notre framework pour un client… qui ne signera pas au final. Entre chaque déploiement, j’avais 4mn de temps libre. Du coup j’avais le temps de descendre prendre un café, parler avec le chef produit, regarder mes mails, et enfin voir mon serveur se planter comme une m… car il nous manquait un JAR.
Cher lecteur, avec Glassfish, terminé la pause café et la discussion avec l’hôtesse de l’accueil : à peine 2 secondes pour démarrer… et encore sur un ordinateur portable… Dingue.
L’explication de ce démarrage rapide est qu’il y a moins de code inutile et de recherche de dépendances pour s’injecter furieusement un Bean comme un drogué… A croire que l’injection de dépendance est devenu maintenant le shoot de votre code… Personne ne parle des applications avec 200 beans qui mettent 2 minutes à démarrer, comme chez BilletTel… Moi je vous en parle.
Glassfish démarre tranquillement ce dont vous avez besoin, ni plus, ni moins. Effet numéro 2 : Alexis modifie du code Java dans une Servlet, effectue un joli Ctrl+S et un F5 dans Safari… hop la page s’est rechargée… Et je vous parle d’une Servlet, pas d’une JSP ! Et j’ajoute que Glassfish conserve la session de l’utilisateur, qu’il n’est pas nécessaire de redémarrer le serveur… qui de toutes les façons démarre rapidement. Si nous ne devons pas relancer le serveur, à quoi cela sert-il qu’il démarre rapidement ?
En conclusion, j’ai vraiment aimé cette présentation de Glassfish. J’avais zappé ces sujets faute de temps à Devoxx, et c’est donc avec un oeil neuf que j’ai assisté ce soir aux présentations. Antonio nous a donné un état de l’avancement de JEE6 qui donne cependant à réflechir, sur ce qu’il sera possible d’utiliser prochainement ou pas. Alexis a présenté Glassfish, un serveur que vous auriez tort d’ignorer, ou tout du moins à ne pas regarder.
Prochain rendez-vous exceptionnel le 10 février à la FIAP afin de fêter les 1 an du Paris JUG avec la venue des JUG leader de toute la France (Tours, Nantes, Bordeaux, Nancy, Nice…) ainsi que la venue de l’organisateur de Devoxx qui présentera son site http://www.parleys.com sur lequel vous pouvez retrouver les conférences de Devoxx.
Je vous parlerai demain du grand tableau blanc sur lequel chacun a voté, les résultats attendront demain…
[Note] billet corrigé ce matin, merci à Emmanuel Servent pour sa relecture. J’ai terminé tard cette nuit.
Références:
Le site du Paris Java User Group : http://www.parisjug.org/
Le site de Glassfish : https://glassfish.dev.java.net/
Le blog d’Alexis http://blogs.sun.com/alexismp
Le blog d’Antonio http://www.antoniogoncalves.org/
Cocktail le 5 février organisé par SUN Microsystemes de 17h30 à 19h00 chez Demos (http://www.demos.fr/actualites/Pages/cocktail-info-java-glassfish.aspx) avec séance de dédicace par Antonio, 50 livres JEE5 à gagner, inscription obligatoire sur le site de demos.
Merci pour ce compte rendu clair net et précis, je n’ai pas pu aller au jug hier soir, c’est comme si j’y étais. D’ailleurs je viens de lancer le téléchargement de glassfish V3 à la fin de la lecture de cet article.
Merci pour le compte rendu qui est clair, concis et reprend bien la présentation faite ce mardi. Personnellement je m’en suis tenu à la seule présentation de JEE6 et n’ai pas poursuivi la soirée, j’avais déjà mon quota d’ironie pour, au moins, le premier semestre.
Quand Java est sorti, 10 ans déjà [soupir], il s’agissait d’ouvrir son emacs et de taper des .java, de faire du javac *.java et hop on pouvait faire tourner son bout de code. Petit à petit on est venu nous rajouter en pagaille des tas de trucs à grands renforts de sigles: EJB, JSP, JAX, Spring, Hibernate…j’en passe. Perso je n’ai jamais rien compris à tout ces trucs bien qu’étant parmi les plus sollicités de mon équipe de dév Java, mes collègues connaissent tout ça sur le bout des doigts mais ça ne les empêchent pas d’être incapables d’écrire du code propre et correct. D’ailleurs en creusant un peu récemment pour savoir ce qu’était Spring je me suis aperçu de la fumisterie qu’on cache derrière des expressions savantes comme inversion de contrôle, injection de dépendance ou autres, tous ces concepts sont finalement inhérents à n’importe quel code Java écrit un peu proprement mais l’emploi de toute cette sémantique permet de se donner de l’importance.
J’en viens donc à JEE6 où on nous a clairement expliqué que, à force de rajouter du bordel, ejb, singleton et tout le bazar, on ne s’en sort plus et que dorénavant il suffira de rajouter des annotations @ et d’utiliser un container implémentant JEE6 capable de faire tout le boulot. On nous présente comme révolutionnaire le fait que, avec JEE6, on pourra juste coder du Java !!?! Vivement la version JEE7 où on nous expliquera que toutes ces annotations sont bien compliquées et qu’il nous faudra simplement ouvrir un bon vieil emacs et coder comme on aurait toujours pu le faire.
Ceci dit on en serait resté là dès le début on serait, certes, autant avancés mais on aurait pas pu s’amuser à faire des beaux graphiques de petites briques qui s’encastrent et de couches s’implémentant les unes aux autres.
@yo: avec Java EE 6 (et GlassFIsh v3) on est proche de ce que tu décris:
POJO + sauvegarde + reload. Les comportements par défaut (plus de web.xml par ex.) et les annotations rendent le tout simple et l’IDE n’est plus indispensable.