Antonio Goncalves (consultant Java) : "Je pense que le couple Grails-Java a de beaux jours devant lui"

La technologie est très vaste, par quel point suggérez-vous de commencer pour maîtriser l'environnement ?

Comme vous le dites, la technologie est très vaste. Java EE est constitué de 23 spécifications et répond à différents besoins. Donc, selon vos besoins, le point de départ peut être différent. Dans mon livre Java EE 5, je développe une application intranet-internet. Je commence par la couche basse (les objets persistants avec JPA), puis je remonte dans les couches (EJB, JSF puis JSP) pour enfin traiter l'interopérabilité (services web, JMS). Cette approche "bottom-up" m'a paru plus pertinente pour l'approche pédagogique. C'est ce que je vous conseille pour débuter Java EE 5.

Quels sont les principaux déficits de JEE 5 ?

Quels intérêts aurais-je à utiliser les technologies Web de JEE 5, plutôt que Ruby on Rails, Grails ou les différents framework Web PHP ou Python, qui apparaissent comme nettement plus simples à maîtriser et mettre en place ?

Ces technologies ne sont pas incompatibles. Je travaille actuellement sur la migration de l'application Web du livre vers Grails qui communiquerait avec les stateless EJB en back-end (puis JPA et les services web). Pour quoi, effectivement, ne pas utiliser la simplicité de Grails pour la présentation avec la puissance de Java EE pour le back-end.

Bonjour, nous avons des besoins très forts en termes métiers (traitements complexes, architecture technique distribuée et besoin d'évolutivité fonctionnelle élevé). Notre architecture PHP 4 ne convient donc plus. J'ai personnellement envie de me tourner vers J2EE. Une question cependant me pose quelques problèmes. Notre designer, habitué à manipuler du HTML, ne connaît rien à JSF ou JSP et entrer dans ce monde lui demanderait un temps certain. Que pourriez-vous nous dire sur la "learning-curve" JSF et sur l'existant en termes d'aide au design Web côté J2EE ? Le développeur Java "métier" ne doit-il pas passer du doté du design ?

Si vous avez une perle de développeur Java "métier" qui connaît le design, surtout ne le laisser pas quitter votre équipe, cette double compétence est très rare ;o). Pour la séparation du graphisme et de la logique de navigation et d'affichage, Java EE s'est amélioré en introduisant au fur et à mesure les JSP, JSTL puis JSF. JSF utilisent des balises XML (donc facilement utilisable par un designer) pour les contrôles graphiques (combobox, list, textfield....). Pour ce qui est spécifique à votre application, votre développeur métier Java peut créer des balises avec JSTL que votre designer utilisera. Ensuite, pour les colories et les images, il reste bien évidemment CSS.

Les processus de migration sont toujours des étapes cruciales. Quelles sont les stratégies de migration proposées par la spécification JEE 5 pour des événements déjà sous JEE 1.4 ?

La spécification Java EE 5 ne parle pas de migration. Elle vous assure que vos applications développées en J2EE 1.4 fonctionneront à l'identique sur des serveurs d'applications Java EE 5. Ensuite, charge à vous d'adopter une de ces deux politiques : vous développez vos nouvelles applications en Java EE 5 et les faites cohabiter avec vos applications J2EE 1.4, soit vous migrez la totalité de vos applications en Java EE 5. Cette dernière solution est, bien évidement, plus coûteuse et peut-être pas très pertinente.

Quels produits implémentent Java EE 5 aujourd'hui ? C'est pas trop tôt pour se lancer ?

Lorsque je me suis lancé dans l'écriture de ce livre en septembre 2006, il n'y avait que GlassFish (l'implémentation de référence) de disponible. Aujourd'hui BEA et JBoss ont franchit le pas. Pour ce qui est de se lancer, la spécification a bientôt un an (et oui, déjà). GlassFish va rentrer dans sa version 3 et les autres serveurs sont rentrés dans la course. Je pense que pour les nouveaux projets, Java EE 5 est une solution à étudier de très prêt car son mot d'ordre c'est "simplicité". Vos équipes auront une petite phase d'apprentissage qui sera vite gommée par le gain de productivité.

Le fait de s'appuyer sur la base de données inclue à Java 6, c'est un avantage ou pas ?

Lors de l'écriture du livre je me suis retrouvé devant de multiples choix à faire (Maven vs Ant, MySQL vs Derby, TopLink Essentials vs Hibernate...). Le but du livre étant de couvrir Java EE 5, j'ai laissé de coté tout ce qui aurait pu l'alourdir pour des raisons pédagogiques. Il s'avère que l'utilisation de Derby dans GlassFish est assez intuitive, mais vous trouverez bientôt sur mon site (www.antoniogoncalves.org) la marche à suivre pour passer à MySQL.

Bonjour, et tout d'abord bravo pour ton livre Java EE5 dont je possède déjà un exemplaire car c'est une vraie référence qui manquait pour la version 5. Penses-tu que GlassFish va rapidement faire de l'ombre à JBoss côté serveur d'applications Open Source ?

Merci. En tant qu'ancien de BEA, je suis habitué à Weblogic que j'utilise fréquemment chez mes clients (depuis la version 4.5.1 ;o) et que j'apprécie. Pour les cours que je donne au Cnam depuis 4 ans, je demande à mes élèves d'utiliser JBoss. Avant d'écrire ce livre je ne connaissais pas GlassFish, mais je n'avais pas le choix car c'était la seule implémentation à l'époque. Je l'ai rapidement pris en main et ai trouvé son administration très intuitive (console d'admin et utilitaire asadmin). Depuis, je n'utilise que lui et je suis en train de migrer tous mes cours du Cnam vers GlassFish. Sun a fait d'énormes progrès dans ses implémentations, GlassFish est un concurrent très sérieux. Je vous conseille de suivre la version 3 qui est très prometteuse.

Vous mettez en avant UML. Quel niveau de complexité applicative peut-on atteindre à partir de modèle UML ?

Je suis un partisant d'UML que j'utilise de manière approfondie depuis de longues années. Des diagrammes de classes que tous les developpeurs utilisent, je suis passé aux diagrammes de déploiement, de composants, de paquetages (sous-systèmes) qui vous donnent une vision globale d'un système. Par contre, si vous voulez parler de la génération de code et du reverse-engineering, je ne suis pas un adepte. Le but d'UML est avant tout d'être compris par différents interlocuteurs (les 4+1 vues), la génération de code est venue ensuite avec les outils. Je suis passé de Rational Rose à Together en passant par StarUml et enfin Visual Paradigm mais aucun ne m'a vraiment convaincu dans la génération de code.

UML est-il facile à prendre en main pour un développeur Java ?

UML 2 est une spécification de plusieurs milliers de pages, c'est donc un langage complexe à prendre en main. Par contre, il y a plusieurs niveaux d'utilisation d'UML. Je pense que les diagrammes de classes et de séquences sont très intuitifs pour les développeurs Java (et je vous conseillerai de commencer par là), par contre, les diagrammes de composants ou de déploiement le sont moins (sans parler du langage de contrainte OCL).

Que pensez-vous du passage de Java en Open Source ?

Ha... Une guerre de religion. 50% des développeurs doivent être pour alors que les autres 50% sont farouchement contre ;o). Pour ma part, je pense qu'il était temps. Pour preuve, l'inspiration de Java EE 5 des framework Open Source : xDoclet, Hibernate, Struts, et j'en passe, sont à la genèse de Java EE 5. Je pense que la mise en Open Source du langage permettra de pareilles avancées.

La spécification EJB semble avoir évolué dans le bon sens en se simplifiant. Le passage des fichiers XML de déploiement (auxquels on s'était difficilement habitué !) aux annotations java 5 est semble-t-il vraiment révolutionnaire en termes de productivité ?

Oui... mais attention. Il y a 10 ans lorsque XML s'est répandu comme une traîné de poudre, tout le monde pensait que c'était révolutionnaire. On pouvait développé un EJB, le compiler, et le packager avec un descripteur XML modifiable à souhait. 10 ans plus tard, plus personne ne veut voir de l'XML, nous en avons fait une over-dose. Les annotations simplifient le développement, soit, j'ai juste peur que les développeurs en mettent partout et que de simples Pojos deviennent rapidement illisibles (annotations JPA + annotations JAXB par exemple).

Que pensez-vous du framework Groovy, et sa capacité à compléter Java ?

Je me suis intéressé à Groovy depuis quelques mois. Le langage est facile à appréhender pour un développeur Java (j'ai essayé Ruby il y a quelques années mais je n'ai pas accroché) et j'ai rapidement pris l'environnement en main et développé mes Hello World. Je me suis récemment mis à Grails pour le développement d'applications Web. Je pense que le couple Grails-Java a de beaux jours devant lui. Ces deux technologies sont complémentaires en termes d'architecture (Grails pour le front-end et Java EE pour le back-end), mais aussi pour la persistance (j'ai été séduit par Gorm).

Je remercie le Journal du Net de m'avoir accueilli, ainsi qu'à tous les intervenants du chat. J'espère avoir répondu à toutes vos questions, si ce n'est pas le cas, vous pouvez me retrouver sur les forums de mon site.