J’ai déjà abordé rapidement le cas de Spring Roo, qui est depuis passé en version stable 1.1.0, proposant une génération de la couche graphique avec au choix Spring MVC ou GWT (en version 2.1, dont la version stable est parue le même jour).

J’ai actuellement l’occasion de travailler sur plusieurs projets dont l’architecture technique est imposée par les normes du client (Hibernate + JPA, Spring, etc.). Ces normes cadrent ce qu’il est possible de faire, et en particulier, elles excluent un certains nombre de frameworks « de productivité » (Grails, Play, etc.). C’est sur ces projets que Spring Roo présente tout son intérêt, car il permet d’appliquer les mêmes principes que ces frameworks, et de gagner en productivité.

De plus, la syntaxe des scripts Roo étant assez simple, il est possible de développer des plugins UML permettant de générer automatiquement ces scripts à partir du modèle de données (et voilà comment on reprend aussi les bonnes idées du MDA en plus).

C’est donc cette approche et ces outils que nous utilisons sur les projets de ce type (architecture imposée à base de Spring) : effectivement, c’est un framework qui permet de largement gagner en productivité. De plus, on peut se séparer de Roo quand on le souhaite (quand le projet est suffisamment mature) dans le cycle de développement.
Cependant, nous sommes récemment tombés sur un petit soucis, indirectement lié à Spring Roo. Pour faire gagner du temps de développement, il doit être utilisé dans un IDE qui le gère, en l’occurrence Eclipse (ou Spring Tools Suite) avec les fonctionnalités de « weaving« .

Or cet outillage est assez gourmand en mémoire (mais avec Eclipse, on est habitué diront les mauvaises langues développeurs réalistes). Cela ne gène pas trop pour les petits projets, mais avec un vrai projet constitué d’un modèle de plus de 100 entités, cette consommation excessive a pris des proportions déraisonnables : Eclipse consomme au minimum 1,4 Go de mémoire pour faire sa compilation incrémentale (sans aucun serveur applicatif lancé) et rame trop pour être utilisable. En restant sous Eclipse, cela nous obligeait à nous séparer de Roo beaucoup plus tôt que prévu, et donc de perdre les fonctionnalités associées pour la suite des développements.

IntelliJ IDEA 10

IntelliJ IDEA 10

Heureux hazard de calendrier, c’est à peu près au même moment qu’est sorti IntelliJ IDEA 10. J’ai déjà eu l’occasion de dire le bien que je pensais de cet IDE, mais la version 9 ne gérait pas Spring Roo. Parmi les nombreuses nouveautés de cette version 10, plusieurs m’ont intéressé : les performances accrues, la gestion native des dépôt Github, la meilleure intégration Maven (les graphs de dépendance sont vraiment bien fichus)… et presque tout le reste en fait, mais particulièrement la gestion des dernières sorties de Spring, dont notre Spring Roo.

Je me suis donc empressé de vérifier ce que cela donnait sur notre projet agonisant sous Eclipse. Effectivement ça marche :

  • les aspects sont correctement liés à leur classe et interprétés : lors de l’auto-complétion sur un objet, les méthodes des différents aspects sont bien proposées.
  • comme d’habitude avec IDEA, le refactoring est bluffant (il propose de renommer également les accesseurs associés à un champ, trouve les utilisation du champ dans les fragments JSPx, etc.) et fait gagner un temps précieux

Le tout avec une fluidité impeccable et pour moins de 200 Mo de mémoire !

En revanche, contrairement à « Spring Tools Suite », Roo ne tourne pas en tâche de fond, et on perd certaines des automatisations liées (méthode « toString() » qui n’est plus mise à jour automatiquement si on ajoute manuellement une propriété à un bean, etc.).

Mais à mon avis, ces quelques désagréments sont largement compensés par le gain de performances dans les développements Roo, et IDEA permet d’utiliser cet outil sur des projets d’envergure là où Eclipse montrait malheureusement ses limites…

[Troll]Ce mardi, au Paris JUG, après une excellente présentation d’Olivier Croisier, une question a été posée par un des leaders du JUG sur un éventuel équivalent Java des Partial Class en .NET. Mais en fait… ça existe en Java ! Je n’ai pas relevé sur le moment… mais c’est exactement ce que fait Spring Roo en séparant la classe principale (composée uniquement des attributs et des méthodes métiers) des accesseurs (dans un fichier AspectJ dédié) et de la gestion de la persistance (encore dans un autre fichier AJ dédié). Et pour rester dans le thème de la soirée, le lien entre tout ça est géré… par des annotations ![/Troll]