Interview d'Alexis MP sur Glassfish V3, les JUGs et sa vision par rapport au rachat d'Oracle

* Pourrais-tu expliquer qu'est ce que HK2 et OSGi ?

Commençons par OSGi. Il s'agit d'un système de modules pour Java né dans l'embarqué, popularisé par Éclipse et désormais relativement populaire côté serveur. Pour faire simple, un module est un ensemble de fonctionnalités, une version, des dépendances vers d'autres modules et un API public exposé (le reste étant de l'ordre du détail d'implémentation). HK2 est en quelque sorte le coeur de GlassFish v3 et la clé de son extensibilité. C'est aussi une couche d'abstraction au dessus d'OSGi (les développeurs de GlassFish v3 n'utilisent pas directement OSGi).

* Pourquoi avoir utilisé ces technologies pour GlassFish v3 ?

OSGi assure les fonctionnalités de système de module, permet d'intégrer un patrimoine de code OSGi existant dans GlassFish et de bénéficier des outils qui viennent avec les implémentations (console par exemple). Et puis cela permet de ne pas réinventer la roue en matière de système de module. GlassFish v3 utilise Apache Felix par défaut. HK2 permet de garder GlassFish v3 cohérent et extensible. Chaque module contribue à un serveur qui n'a qu'un seul fichier de configuration (domain.xml), un seul outil en ligne de commande (asadmin) et une seule console d'administration web. Il n'est pas question d'un nouveau conteneur, un mécanisme de persistance où une pile web services vienne avec son propre fichier de configuration par exemple. Ce serait vite ingérable pour l'utilisateur. HK2 permet également de changer le système de module si nécessaire. GlassFish fonctionne également sur Equinox, mais aussi dans un mode statique (sans OSGi). Si un nouveau système (par exemple intégré au JDK) apparaît, l'adaptation nécessaire dans GlassFish sera minimale. Sur ces deux sujets, le blog de Jérôme Dochez, architecte de GlassFish, est une bonne source d'information : http://blogs.sun.com/dochez (question "à la carte" traitée dans la question suivante).

* Qu'apporte la v3 au niveau des conteneurs ?

Dans GlassFish v3, un conteneur est un module. Il peut être désactivé, voire même absent. Les conteneurs les plus connus fournis par défaut sont : servlet, ejb, jax-rs (jersey), jms, jsf, jax-ws (metro), jca, et jpa (eclipselink). Les autres conteneurs disponibles sont surtout liés aux environnements et frameworks d'autres langages pour la JVM: Groovy/Grails, JRuby/Rails, Jython/Django, ... L'existence même de ces modules bien définis permet de fournir GlassFish deux distributions : web ou complet (profils définis dans Java EE 6), mais aussi de faire son serveur à la carte. On peut ainsi créer une distribution hybride répondant uniquement aux besoins de l'application exécutée (et par exemple, proposer quelque chose de très petit). J'ai réalisé à ce titre quelques petites vidéos : http://blogs.sun.com/alexismp/tags/alacarte

* Tu as fait de multiples présentations de GlassFish v3, comment ressens-tu la communauté vis-à-vis de GlassFish ?

Les retours sont souvent très bons. Certains retiennent l'aspect modulaire, d'autres les fonctions de redéploiement à chaud avec préservation de la session, d'autres encore le support de Java EE 6. Disons que le commentaire le plus fréquent c'est quelque chose comme : "dommage que ce ne soit pas plus connu" ou "pourquoi ne faites-vous pas plus de pub?".

* Quelle est (ou sont) la nouveauté la plus intéressante de GlassFish v3 par rapport à v2 ?

J'en retiendrais trois : - modularité (OSGi et HK2 comme décrit plus haut) - support complet de Java EE 6 (ça ne vaut pas les nouveautés de Java EE 5, mais cela créées beaucoup d'intérêt après que ce dernier ait permis de remettre Java EE sur les rails). - l'expérience utilisateur/développeur: démarrage et redéploiement rapide, préservation des sessions lors de redéploiement, occupation mémoire proportionnelle à l'usage des modules. GlassFish c'est une peu de légèreté dans ce monde de brutes des serveurs d'applications Java EE !

* Quels sont les éléments différenciateurs de GlassFish par rapport à d'autres serveurs d'applications ?

Par rapport aux offres commerciales, il est Open Source. C'est évident, mais ça vaut le coup de le rappeler. Cela contribue largement à son adoption par une large communauté d'utilisateurs, voire dans certains cas de contributeurs.

Je pense que l'architecture (HK2) pensée par Jérôme donne à GlassFish un nouveau souffle technologique tout en étant très pragmatique. Le support des derniers standards (Java EE 6, JAX-RS), mais aussi de technos comme Comet et plusieurs environnements dynamiques (Rails, Grails, Django) sont des points assez uniques. On peut aussi citer la partie gestion de paquetage de GlassFish (techno IPS/pkg) qui permet de gérer les modules du serveur comme on gère les paquetages d'une distribution Linux.

Enfin, je pense que c'est un des rares produits susceptibles de plaire à la fois aux développeurs et à une population de production. Cette propriété a souvent été un critère de choix important en faveur de GlassFish.

* Les évolutions à venir après la v3 ?

V3 est assez similaire à ce qui a été fait avec GlassFish v1: support complet de Java EE (5 à l'époque) mais en mode mono-instance. Le partage et de charge est de la responsabilité de l'utilisateur (mod apache par exemple). GlassFish v3.1 sera donc focalisé sur l'intégration de l'administration centralisée qui existe aujourd'hui dans la 2.x ainsi qu'à l'intégration des solutions de clustering et de réplication. Cette version 3.1, prévue courant 2010, sera à équivalence fonctionnelle avec la famille v2.x et rajoutera des fonctionnalités permettant de faciliter le déploiement de GlassFish dans des environnements virtualisés de type "Cloud".

* Java EE 6 et GlassFish, pourquoi utiliser GlassFish ?

Parce que Java EE 6 est une version de maturité par rapport à Java EE 5 avec un bon équilibre entre nouveautés et améliorations à la marge, mais aussi parce que GlassFish n'est plus (depuis un certain temps d'ailleurs) qu'une implémentation de référence, mais bien un produit open source capable de rivaliser en fonctionnalités et performances avec tous les autres acteurs de ce marché.

* Une des difficultés à imposer GlassFish en ce moment vient de l'incertitude de son évolution après le rachat par Oracle.

La FAQ publiée par Oracle fin octobre 2009 devrait rassurer très largement sur l'avenir de GlassFish : http://www.oracle.com/us/sun/038563.pdf GlassFish est open Source, implémente Java EE 6 aujourd'hui, et plait aux développeurs ainsi qu'à la production. GlassFish continue d'attirer de nombreux nouveaux clients, y compris dans cette période de transition. GlassFish v3 est une architecture élégante de modularité qui lui apporte une nouvelle jeunesse. Il existe déjà de nombreuses collaborations techniques entre GlassFish et Weblogic: Metro, EclipseLink, JSF, etc...

* Quelle est ta réaction vis-à-vis du rachat par Oracle ?

J'ai clairement approfondi ma connaissance d'Oracle depuis l'annonce du rachat... C'est une société qui a en commun avec Sun une culture de l'engineering. Contrairement à Sun, Oracle n'a par contre pas pris le virage de l'Open Source de manière aussi radicale. Cela dit, tous les rachats de technologies open source effectués (InnoDB et Sleepycat/BerkleyDB par exemple) sont restés Open Source (difficile de faire autrement), avec la même licence (c'est déjà plus parlant) et avec des ressources de développement renforcées. Oracle a même mis TopLink (issu également d'une acquisition et désormais nommé EclipseLink) en Open Source il y a quelques années.
Il y a une très belle opportunité pour Oracle d'intégrer dans ses rangs une équipe d'ingénieurs innovants et de leur donner des moyens de réussir, ce qu'Oracle a su déjà très bien faire en élargissant régulièrement son périmètre d'action. Je suis donc optimiste.

* Comment vis-tu le succès des aquariums, et que comptes-tu faire pour les faire évoluer ?

Un des principes de fonctionnement de l'équipe GlassFish c'est "Think globally, act locally" soit littéralement "Penser globalement, agir localement". C'est pour cette raison que Sun essaye d'organiser des rencontres régulières sur ses technologies. Cela dit, il existe beaucoup d'autres initiatives (les JUGs en font partie) similaires et il me parait important de savoir travailler ensemble pour produire des événements de qualité. Pour ce qui est des réunions Aquarium, je suis content d'avoir fait participe des utilisateurs (clients, partenaires) aux dernières réunions. On obtient souvent un bon équilibre de contenu en combinant technos et retours d'expérience. A noter que le 10 décembre, l'institut de formation Demos, partenaire de Sun, organise une soirée pour le lancement de Java EE 6 et de GlassFish v3 (détails à venir).

* Que penses-tu de JavaFX, d'android...

C'est intéressant (et assez inhabituel) de citer ces deux là dans la même question. Je pense qu'ils ont beaucoup de similitudes notamment par leur utilisation d'une machine virtuelle, ce qui est assez différent de l'initiative Open Web Foundation (HTML5...) dont pourtant Google est à l'initiative. JavaFX propose une exécution multipériphérique sur poste de travail et sur téléviseur en plus des téléphones mobiles. Pour le reste, l'adoption d'Android semble réelle et régulière.

* EDI Sun/Oracle

Cf. le même document référencé plus haut: http://www.oracle.com/us/sun/038563.pdf

* Comment expliques-tu l'explosion tardive des JUG en France ?

Très honnêtement je ne me pose pas la question, je savoure la création de chacun d'entre eux. C'est à la fois assez naturel de voir des gens de regrouper autour d'une technologie aussi répandue, mais aussi très encourageante de voir des salles aussi combles tous les mois près de 15 ans après la création de Java. Je me disais qu'en faisant la somme de tous les événements des JUGs en France sur une année, on approche doit s'approcher de l'audience de JavaOne.

* Qu'aimerais-tu voir sur developpez.com qui manque actuellement ? Peut-être des sessions de discussion ou des présentations en direct, des événements ponctuels en quelque sorte. Je pense qu'il y a beaucoup de francophones qui travaillent sur des produits et des technologies intéressantes (glassfish et jboss sont de bons exemples) qui sont susceptibles de venir présenter leur travail. Cela renforcerait je pense la notion de communauté de développez. Le sujet à traiter pourrait venir directement de la communauté developpez.com.

Forum NetBeans
Forum GlassFish
https://java.developpez.com/interview...urce/alexismp/
http://blogs.sun.com/alexismp/
http://blogs.sun.com/theaquarium/
https://www.developpez.net/forums/d70...donner-accord/

Je tiens à remercier Alexis Moussine Pouchkine, pour le temps qu'il a pris à me répondre.

Tout autant, je tiens à remercier ram-0000 et Ricky81 pour leur relecture.