Découverte de IntelliJ IDEA

Je pourrais titrer ce billet « Confessions d’un éclipsien repenti », mais on m’accuserai de mauvais plagiat… et malgré la très bonne impression que m’a faite IntelliJ IDEA, j’apprécie toujours également mon fidèle Eclipse.

Mais revenons un tout petit peu en arrière… Depuis plus d’un an, j’entends parler de cet IDE : blogs, un récent comparatif, le Paris JUG, etc. J’avais donc décidé d’y regarder de plus près, mais sans jamais vraiment prendre le temps de m’y mettre. J’en ai eu récemment l’occasion, en testant le Play! Framework. Celui-ci dispose en effet d’une commande « idealize » permettant de générer le projet au format IDEA, qui n’a pas d’équivalent pour Eclipse. J’ai donc décidé de faire d’une pierre deux coups et de tester Play! en même temps qu’IntelliJ IDEA.

J’ai rapidement beaucoup apprécié les fonctionnalités de l’IDE, et j’ai donc étendu mon test à un projet Java/J2EE. Voici pas à pas le déroulement de ma découverte de l’IDE, pour les retardataires qui, comme moi, n’avaient pas encore franchi le pas…

Généralités

Quand on arrive dans l’IDE, l’interface ressemble à celle d’Eclipse… et à celle de tous les autres environnements de développement. Mais deux choses sont immédiatement remarquables : la sobriété et la fluidité de l’interface (plus légère que celle d’Eclipse), et la faible consommation mémoire de l’IDE, affichée en bas à droite, avec la possibilité de déclencher un « Garbage Collector » quand on le souhaite. Moins de 100 Mo de mémoire au démarrage, ça paraît surréaliste quand on a l’habitude d’Eclipse !

Beaucoup de choses sont en mises en place pour favoriser la migration des utilisateurs d’Eclipse :

• les projets Eclipse (fichiers .project, .classpath, etc.), peuvent être importés directement dans IDEA
• les raccourcis IDEA par défaut sont différents de ceux d’Eclipse. Mais dans « Settings > Keymap », il est possible de surcharger ces raccourcis par ceux d’Eclipse, de Netbeans, JBuilder, etc.

On remarque au passage que ces « Settings » sont proches de ceux d’Eclipse, et permettent de complètement paramétrer l’éditeur (style de code, options, etc.).

Il y a juste un point de vocabulaire sur lequel je me suis laisser piéger au début, étant habitué à Eclipse : les « workspaces » Eclipse n’ont pas d’équivalent sous IDEA. Le répertoire racine pour IDEA représente un « projet« , et il n’est pas possible (ou alors, je n’ai pas encore trouvé) de grouper plusieurs projets dans une unique fenêtre. Un projet IDEA peut toutefois être constitué de plusieurs « modules« , ce qui permet de gérer les projets multi-modules (pour Maven, par exemple).

Utilisation de Git avec IDEA

La gestion de configuration avec Git

Dans IDEA, Git est géré nativement sans avoir à installer de plugin, de même que CVS et Subversion (Mercurial sera supporté dans la prochaine version majeure, et d’autres gestionnaires de configuration sont disponibles dans la version « Ultimate« ).

Mais la grosse différence avec EGit, même si ce dernier avance très vite, c’est que le support d’IDEA est beaucoup plus complet, avec la gestion du « stash« , mais surtout une gestion très complète du « rebase » (comprenant le rebase interactif).

On ne coupera pas à la ligne de commandes Git pour certains besoins (ajout interactif de portions de fichiers à l’index, utilisation des commandes de synchronisation avec SVN, etc.), mais comme avec Eclipse, on s’en sortira sans problème avec les « External Tools » (qu’il est au passage très agréable de pouvoir classer par catégories).

Il y a juste une limitation que j’ai trouvé génante, mais elle n’est pas spécifique à Git : elle provient du fait qu’il n’existe pas de « workspace » dans IDEA. Pour un même projet, il n’est pas possible de définir plusieurs gestions de configuration différentes (dans le cas où on en souhaiterait une différente par module).

Gestion de Maven par IDEA

Utilisation de Maven

La gestion de Maven intégrée à IDEA (là encore sans plugin additionnel) est vraiment bien faite :

• les fonctions d’auto-complétion du « pom.xml » (et des autres fichiers Maven) sont très poussées. A chaque niveau, l’auto-complétion ne proposera que les options réellement disponibles. Par exemple, dans la configuration du « maven-compiler-plugin« , IDEA me propose « source« , « target« , etc. dans la liste des options disponibles.
• la fenêtre de lancement des commandes Maven détecte automatiquement les profils disponibles (qu’ils soient dans « settings.xml« , « profiles.xml« , ou encore le « pom.xml« ), les plugins utilisés sur le projet et les différents goals disponibles pour chacun de ces plugins.

Etant habitué à Eclipse, j’ai passé un peu de temps à comprendre comment créer et sauvegarder des configurations types (plusieurs goals lancés successivement, avec une liste déterminée de profils) : il faut faire un clic droit sur un des « goals » que l’on souhaite personnaliser et choisir « create Run/Debug configuration« . On peut alors customiser le La nouvelle configuration qui deviendra disponible dans « Run/Debug« . Mon seul regret est que ces configurations personnalisées ne soient accessibles que par ce menu et ne reviennent pas s’incruster dans une nouvelle branche de l’arbre de gestion de Maven.

Debugger intégré

Afin de tester le mode debug d’IDEA, j’ai ainsi créé une configuration Maven basée sur « Jetty:run », en ajoutant dans le champ « VM Parameters » :

1

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5555

Il ne reste plus qu’à créer une configuration « Remote« , en précisant le port de communication :

Configuration du debugging distant

Après avoir posé un point d’arrêt sur l’action de test, je lance successivement « Maven > Jetty DEBUG« , puis « Remote > Jetty DEBUG« . Ca fonctionne sans aucun accroc, et lorsque je lance la page de test, IDEA intercepte bien mon l’action au niveau du point d’arrêt. Concernant la vue « DEBUG » elle même, c’est très classique : introspection des variables, modification des valeurs à la volée, exécution pas à pas, possibilité de capturer un « Thread dump« …

Outils d’analyse et de refactoring

Terminons par le meilleurs : la grosse claque, ce sont les outils d’analyse et de refactoring disponibles dans l’IDE :

• Qualité de code
• Dépendance cycliques
• Etc.

Jusqu’ici, rien d’extraordinaire : on retrouve les analyses classiques de PMD, CheckStyle, FindBugs, et autres outils… Mais là où IDEA est bluffant, c’est qu’il propose de refactoriser le code tout seul pour supprimer un grand nombre de ces anomalies.

Par exemple, pour ne citer q’un cas très simple et classique :

1
2
3
4
5
6

public boolean isQuelqueChose() {
    if(conditionAlambiquee) {
        return false;
    }
    return true;
}

que l’outil d’analyse/refactoring d’IntelliJ IDEA proposera de remplacer par :

1
2
3

public boolean isQuelqueChose() {
    return !conditionAlambiquee;
}

En faisant des tests et en créant plusieurs individus de la même famille « Courtine », j’ai pu voir que l’outil détectait que la méthode de mon bean « setNom(String nom) » était toujours appelée avec le même paramètre. il m’a donc aimablement proposé de remplacer cette méthode par « setNom() » sans paramètre avec le nom « Courtine » en dur dans le corps de la méthode. Pour un bean, ce n’est pas top… Bilan : il ne faut pas accepter aveuglément toutes les propositions de l’outil, mais ces fonctionnalités d’analyse/refactoring automatique restent vraiment géniales, et permettent de nettoyer très rapidement et sans risques une bonne partie du code de veilles applications.

Conclusion

J’ai donc été vraiment impressionné par IntelliJ IDEA, uniquement avec la version « Community », et ce même si je suis encore très loin d’avoir fait le tour du produit (je n’ai en particulier pas encore testé son système de plugins). J’envisage donc déjà très sérieusement de remplacer mon Eclipse, malgré ses longues années de loyaux services.

Enfin, au vu du comparatif des versions et des possibilités de la version « Ultimate » (support des serveurs d’application professionnels, nouveaux outils d’analyse, debugging des JSP et du code javascript, etc.), je pense que je ne vais pas tarder à en acquérir une licence…

Finalement, cet IDE m’a tellement plu qu’il m’a détourné de mon but premier qui était de tester Play! Framework… Maintenant que j’ai pris le temps de jouer avec l’outil de développement, je vais pouvoir me remettre à jouer avec Play!

Je pourrais titrer ce billet « Confessions d’un éclipsien repenti », mais on m’accuserai de mauvais plagiat… et malgré la très bonne impression que m’a faite IntelliJ IDEA, j’apprécie toujours également mon...