Vous aimez ce que vous lisez sur ce blog ?
Envie d'aller plus loin avec véritable formation d'expertise en Java ?
Venez suivre ma formation Masterclasse Expertise Java !

"Même un développeur experimenté a besoin de continuer à apprendre. Et dans cette formation... j'ai appris beaucoup !" - A.G., Java Champion

Prochaines sessions inter-entreprises : 28-31 mars 2017 / 13-16 juin 2017
Sessions intra-entreprises sur demande.
Inscrivez-vous vite !

SpringOne, DayOne - Keynote de Rod Johnson

SpringOne, premier jour.

Malgré un ciel bas et lourd (avec un soupçon de pluie) pesant comme un couvercle sur l'esprit gémissant en proie aux longs ennuis des passagers du Thalys (2h de retard, merci bien), j'ai tout de même rejoint Amsterdam à temps pour assister à la fameuse Keynote de Rod Johnson, qui ouvrait la conférence.

Au programme, son analyse de l'actualité et sa vision du futur de Java, puis un tour d'horizon du portfolio SpringSource, et même quelques annonces exclusives. Suivez le guide !

The future of Java innovation

Personne n'est resté insensible à l'annonce du rachat de Sun Microsystems par Oracle, pour la modique somme de 7.4 milliards de dollars (soit 237,95€ au cours du jour), et la communauté Java se demande à quelle sauce elle va être mangée. Quelles sont les motivations d'Oracle ? Est-ce un simple mouvement stratégique pour couper l'herbe numérique sous le pied d'IBM, ou cela fait-il partie d'une stratégie à long terme ? La "marque" Java représente-t-elle un réel atout commercial ?

En réalité, Oracle pourrait bel et bien s'octroyer des avantages concurrentiels importants en influançant les JCP (et donc la norme JavaEE), mais ne pourra pas contrôler l'écosystème Java dans son ensemble, grâce à son immense communauté, dont Google, la fondation Apache, et... IBM en personne, ne serait-ce qu'à travers la fondation Eclipse. Et le langage lui-même est maintenant open-source ! Alors pourquoi racheter Sun ? Pour sa rentabilité ? Depuis plusieurs années, le soleil s'est voilé et la firme est déficitaire sur la plupart de ses activités, bien loin des 70% de marge auxquels Oracle est habitué ; de sévères restructurations et de nombreux licenciements sont donc à craindre. Pour insuffler une vision nouvelle dans le monde de la programmation opensource, alors ? Oracle n'est clairement pas connu pour ses prouesses en la matière, ni pour la puissance de son innovation.

La question est donc : quelles répercussions tout ceci aura-t-il sur SpringSource ?
En réalité, Rod Johnson se frotte les mains. Cela peut paraître surprenant, mais voici pourquoi. La plateforme JavaEE actuelle est beaucoup trop lourde et trop complexe - la fuite des développeurs au profit de plateformes plus légères comme PHP ou Grails ou Ruby on Rails en est un symptôme flagrant, et son passage sous la houlette d'Oracle ne risque pas d'améliorer les choses.

Plus préoccupant, les reproches envers la norme Java EE rejaillissent sur la plateforme entière, qui est pourtant très performante (VM, serveurs d'application, etc.). Il est donc temps de réagir avant que sa mauvaise réputation ne l'enterre définitivement. Pour cela, il faut disposer d'outils et de technologies plus productifs pour regagner l'estime des développeurs et rester compétitif par rapport aux autres plateformes - voire même, les attaquer sur leur propre terrain.

Et c'est très exactement sur ce créneau que se positionne SpringSource, avec une offre intégrée couvrant l'ensemble du cycle de vie des applications : développement, déploiement et exploitation.
Rod Johnson en a d'ailleurs profité pour annoncer la prochaine gratuité de STS (SpringSource Tools Suite), et le support de Groovy et Grails au sein de l'IDE !

Développement

Pour améliorer la productivité du développeur, SpringSource met en avant deux produits :

  • Groovy et Grails, rachetés récemment, qui attirent de nombreux développeurs (Java et non-Java).
  • ROO, un générateur de code intelligent, qui cible les développeurs Java maîtrisant déjà Spring. A ce propos, un concours sera organisé prochainement pour renommer le projet ; commencez à réfléchir !
ROO in action

Ben Alex, développeur de ROO et déjà à l'origine de SpringSecurity (anciennement Acegi Security), a réalisé une démonstration des principales fonctionnalités de l'outil.

Tout d'abord, il a créé un répertoire vide destiné à accueillir le nouveau projet, et à partir duquel il a lancé ROO depuis une ligne de commandes. ROO se présente lui-même sous la forme d'un shell et offre des fonctionnalités d'autocomplétion contextuelle intelligente. A partir de ce shell, voici comment il a créé un projet de type SpringMVC/Spring/Hibernate :

  1. # Créer une hiérarchie standard de répertoires, et définit le "package racine" du projet
  2. create project -topLevelPackage com.springsource.vote
  3. # Ajouter Hibernate et une base de données HSQLDB
  4. install jpa -provider HIBERNATE -database HYPERSONIC
  5. # Créer un objet persistant "Choice", dans le sous-package "domain"
  6. new persistent class jpa -name ~.domain.Choice
  7. # Ajouter un champ persistant "namingChoice" de type String, avec de règles de validation (Cf. JSR 303)
  8. add field string -fieldName namingChoice -notNull -sizeMin 3"

Il a ensuite suffi d'importer le projet dans Eclipse, après avoir utilité Maven pour générer ses métadonnées (mvn eclipse:eclipse).

ROO sous le capot

Jetons donc un oeil au code généré.
Nous voyons bien la classe Choice, qui possède comme prévu un champ namingChoice. Mais à part ça, la classe semble bien vide (pas d'accesseurs), et la couche DAO habituelle est introuvable. Où est donc passé tout le code ?

En réalité, ROO utilise AspectJ pour incorporer dynamiquement des méthodes aux classes métier. Ce processus est piloté par des annotations. Par exemple,

  • @RooEntity fournit des méthodes de persistance : merge(), update(), findAll(), findById(Long id), etc.
  • @RooJavaBean injecte les accesseurs (getters/setters)
  • @RooToString fournit une implémentation basique de la méthode toString().

Notez que toutes les annotations possèdent le même préfixe.

Ce qui est intéressant, c'est que cet assemblage est parfaitement reconnu par SpringSource Tool Suite (c'est-à-dire Spring IDE), et qu'il est possible d'appeler ces méthodes sur la classe de manière transparente : l'autocomplétion fonctionne, le débuggage pas à pas aussi...

La classe métier devient donc le point central de l'application, dont l'architecture devient "domain-oriented" plutôt que "layer-oriented". Les habitués de Grails ne seront pas dépaysés. Par contre, l'aspect "auto-magique" de la chose et la disparition du découpage en couches risquent de déplaire à plus d'un architecte.

Roo et le web

ROO permet également de générer des contrôleurs SpringMVC.
Pour cela, retour au shell ROO :

  1. # Création d'un contrôleur avec mapping automatique de type [REST|http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/]
  2. new controller automatic -name ~.web.ChoiceController
  3. # Après la création d'une entité Vote associant une IP à un Choice particulier, génération du contrôleur associé, cette fois en mode manuel : ce sera au développeur de l'implémenter et de gérer ses mappings.
  4. new controller manual -name ~.web.VoteController
  5. # Installation et configuration de Spring Security. Cela crée un fichier de configuration "application-context-security.xml" qui protège les contrôleurs. Si on essaie d'accéder à une ressource protégée, la page de login apparaît, et après login, l'utilisateur est redirigé vers la page initialement demandée.
  6. install security

Il ne reste plus qu'à déployer l'application web sur un serveur (au hasard, Tomcat ?).

Il est important de savoir que l'application n'est jamais liée à ROO, ni pendant le développement, ni au runtime (mais AslectJ est requis). De plus, il est capable de faire du reverse-engineering sur les classes modifiées par le développeur directement dans l'IDE (hors shell ROO), et de s'adapter aux modifications.

A propos d'IDE, ROO est déjà intégré à Spring IDE et se présente sous la forme d'une vue proposant un shell.

ROO vs Grails

Il n'y a pas de réelle concurrence entre Grails et ROO. Le premier cible les développeurs non-java, ou ceux qui veulent utiliser un langage dynamique (groovy) ; le second vise plutôt les développeurs souhaitant conserver tous les avantages du typage dynamique et la performance d'un langage compilé.

Déploiement

Une fois les applications développées, il faut bien les déployer sur des serveurs.

Rod Johnson prédit la mort prochaine des serveurs d'applications traditionnels : trop de fonctionnalités inutiles, approche monolithique ("one size fits all"), peu productifs... Pour lui, l'avenir est aux serveurs légers, qui répondent à 80% des besoins d'entreprise, et plus important encore, aux attentes des développeurs.

SpringSource, qui embauche les principaux développeurs de Tomcat, propose deux produits qui en dérivent :TC server et DM server.

  • TC Server est un Tomcat auquel ont été ajoutées des fonctionnalités de management avancées (grâce à AMS, l'Advanced Management Suite), et qui bénéficie d'un support commercial. Rod Jonhson vient d'officialiser la sortie de la version 1.0.
  • DM Server intègre une couche OSGi qui permet de découper les applications en modules autonomes, afin de gérer leurs cycles de vies de manière indépendante.

Pour conclure cette session, Jennifer Hickey a réalisé une rapide démonstration des capacités de la console d'administration AMS :

  • Déploiement de l'application sur un cluster de TC Servers, d'un seul clic
  • Modification des paramètres des serveurs (taille de la mémoire et des pools de connexion)
  • Monitoring des serveurs avec remontée d'alertes

Conclusion

Cette première séance était fort intéressante, puisqu'elle nous a permis de connaître la vision et la stratégie de SpringSource sur le marché des applications Java, surtout à la lumière des événements récents, et de découvrir leurs nouveaux produits.


Commentaires

1. Le mardi 28 avril 2009, 06:59 par Alexis MP

Salut Olivier, Oracle c'est 32% de marge. Sun fait du hardware ou les marges ne peuvent pas être les mêmes.

2. Le mardi 28 avril 2009, 08:24 par Nicolas Martignole

Après avoir lu l'article j'ai eu un sentiment assez partagé, voir inquiet sur ROO. Derrière l'idée de nous donner de quoi générer notre code plus facilement, moi je vois un excellent moyen pour SpringSource pour nous locker définitivement. En effet, une fois notre code décoré comme un sapin avec des @RooEntity, il ne sert plus à rien sans le moteur d'AspectJ et ROO, ce qui nous donne une dépendance dangereuse. Personnellement j'attendais une solution qui génère du code classique, plus proche de nos besoins. Pas un machin qui nous donne un sapin de Noël avec 4 boules en nous disant : "pour le reste on s'en occupe".

Je testerai ROO et je pourrai alors en dire un peu plus.

Merci sinon olivier pour ton billet, j'aime bcp le ton et la qualité. Bonne continuation à SpringOne.

3. Le mardi 28 avril 2009, 10:48 par Olivier Croisier

Effectivement, je suis également assez partagé sur ROO. C'est loin de la solution miracle que j'imaginais, en fait, ça se rapproche davantage d'un "Grails sans Groovy", où l'objet métier contient à la fois les données, le code de persistance, la validation... Cela heurte ma petite âme sensible d'architecte multi-couches traditionnel - mais peut-être est-ce une espèce en voie de disparition en cette époque d'agilité à tout prix...

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.