Eclipse, je te quitte … Pour IntelliJ IDEA !

C’est décidé, contre toute attente et après 8 ans de fidélité … je quitte Eclipse.

Pourtant, je l’aime …

Ce genre de décision ne se prends pas à la légère. On aime tous son environnement de développement. On est même convaincu que c’est le meilleur. On y a ses repères, ses habitudes, on y est rapide, concentré, efficace. Il nous rends même plus fort par la productivité qu’il apporte. Malgré le temps qui passe, on y découvre encore certaines fonctions qui prouvent que celui-ci est riche, complet et pratique.

Bien sûr, on y trouve aussi quelques défauts, ou même pire : des bugs ! Mais on s’y fait, on les contourne, et on attends patiemment la prochaine version. Finalement, on y reste parce que on y est accro, et surtout convaincu qu’aucun autre ne fera mieux …

Change Ahead

Change Ahead

Le décors

Depuis peu, je travaille sur la migration d’une application client/serveur (Swing & Embedded Jetty) vers une application HTML5 dans une équipe de 3 personnes. Nous faisons rapidement le choix d’utiliser Vaadin, framework web orienté composant en Java, et nous identifions également quelques librairies JavaScript supplémentaires, comme JointJS qui permet de réaliser des graphes en HTML5/SVG. Plugin Vaadin pour Eclipse ajouté en quelques clics, on commence à coder et tout roule comme d’habitude.

Les ennuis commencent

En quelques jours, les premiers écrans sont portés. Vient alors la création du composant JointJS en JavaScript. J’écris quelques appels en utilisant la librairie, et là … rien ne se passe. J’ai la douloureuse impression d’écrire mon code dans Notepad++. Je pensais naïvement qu’Eclipse serait capable de s’adapter à JavaScript à la perfection. En Python, langage typé dynamiquement, on a le droit a un debug efficace, du code assist dans la mesure du possible, de la navigation sur les méthodes, les attributs, les classes, les modules. Alors pourquoi pas en JavaScript ?

Je me met alors à la quête des options de configuration, de plugins, d’interventions divines. Après deux jours passés à fouiner sur le web, à tout essayer, Eclipse commencer à péricliter dans mon cœur … Quelque soit les outils et plugins utilisés, ça ne fonctionne pas ou trop peu, et les projets ont l’air plutôt abandonnés (JSDT, CrossFire, Ajax Tools Framework, et autres…). A chaque fois le code assist est très mauvais, la navigation bancale, le remote debug défaillant…

Aptana Studio s’en sort légèrement mieux, mais ne détecte pas les modèles Backbone de JointJS, et le remote debug via un plugin Firefox plante carrément.

Pour Java et Python, Eclipse est proche de l’excellence. Mais force est de constater que, dans le cadre d’un projet web en JavaScript, il fait pâle figure.

JavaScript + Eclipse = Bébé qui pleure...

JavaScript + Eclipse = Bébé qui pleure…

IntelliJ IDEA ? Pourquoi pas…

Au fil de mes recherches, j’ai lu de nombreux avis positif sur IntelliJ IDEA, et j’ai même trouvé des articles de développeurs sous Eclipse qui y sont passé. Je décide alors de me faire mon propre avis et d’essayer, dans l’espoir de trouver une solution à la médiocrité du support JavaScript sur Eclipse.

Si l’édition Community est bien gratuite et opensource, elle ne contient pas toutes les fonctionnalités dont j’ai besoin. Pour avoir le support de Python et de JavaScript, je télécharge sur une version d’essai 30 jours de l’édition Ultimate payante.

Premier contact

Au démarrage, IntelliJ IDEA propose une série d’écrans pour désactiver et activer des plugins. Un grand nombre de technologies actuelles sont supportées out of the box. Mon projet, constitué de 3 sous-projets et 20 modules, s’importe en quelques clics via Maven. Je lance ensuite la compilation avec un bouton nommé Make, crée le Run configuration comme sous Eclipse, et démarre l’application… Tout fonctionne bien, et l’environnement de développement est en place 5 minutes après l’installation.

JavaScript

J’ouvre ensuite les fichiers JavaScript du projet, et ô miracle ! Sans rien paramétrer, le code assist est excellent, même sur les objets de JointJS et les modèles Backbone, j’ai une navigation au clic sur les différents objets, qui passe automatiquement de fichier en fichier, et la JSDoc s’affiche…

Dans mon élan, je crée un Run configuration JavaScript Debug, je choisi Firefox comme navigateur et l’URL de mon application. Après l’installation du plugin navigateur, et la création d’un mapping entre les URL et les dossiers contenant les sources JavaScript, tout fonctionne ! Je peux débuguer l’application web, mettre des points d’arrêt sur les fichiers JavaScript, effectuer des évaluations, écrire des espions, et même utiliser la console. Le tout avec la même facilité que dans Firebug, mais dans l’environnement de développement. Le JavaScript Debug supporte également Chrome, ainsi que d’autres navigateurs du marché.

JavaScript + IntelliJ = Bébé heureux!

JavaScript + IntelliJ = Bébé heureux!

Python

Après avoir rapidement testé sur guessit, un projet Python auquel je contribue, IntelliJ s’en sort au moins aussi bien qu’Eclipse avec PyDev. Il semblerait que le plugin Python d’IntelliJ IDEA utilise lui aussi PyDev, au moins pour le débugueur.

Java

Après avoir choisi la keymap Eclipse et ajouté quelques raccourcis manquants, on fini par retrouver facilement ses marques. La plupart des fonctionnalités d’Eclipse sont présentes, comme Call Hierarchy, Type Hierarchy, Quick Fix, Refactoring, Generate Code, …

Un des principal avantage d’IntelliJ IDEA est son support des scopes et classpath. L’intégration de Maven dans IntelliJ est bien plus précise que celle d’Eclipse. Les classpaths issus des différents scopes (compile, test, runtime, provided) sont clairement dissociés. Ce n’est pas le cas dans Eclipse, qui crée un classpath unique.

L’environnement de compilation et d’exécution généré par IntelliJ IDEA est donc beaucoup plus proche de Maven que celui généré par Eclipse. Là ou Eclipse permet d’importer dans les classes principales (/src/main/java) une classe d’une dépendance de scope test, IntelliJ IDEA ne l’autorisera pas en indiquant une erreur d’import, exactement la même erreur que lors de l’execution de mvn compile. IntelliJ permet donc de mieux diagnostiquer et corriger les problèmes relatifs à Maven, en respectant son comportement pour les scopes et classpath.

UI et Simplicité

Au niveau de l’interface utilisateur, IntelliJ IDEA est moins flexible qu’Eclipse. Mais est-ce un mal ?

Dans Eclipse, les notions de workspace et de perspective ont tendance à complexifier les choses. Très franchement, quel est l’intérêt de la perspective Debug ? Si quelqu’un accepte de voir son IDE chamboulé au moment ou le débugueur atteint un point d’arrêt, j’aimerai bien qu’il m’explique pourquoi … Globalement, je n’utilise qu’une seule perspective, quelque soit la technologie employée (Java, Python, JavaScript…), et je ne pense pas être le seul.

Dans IntelliJ IDEA, il n’y a ni workspace, ni perspective. On crée simplement des projet, et chaque projet est indépendant des autres. Un projet est constitué d’un ou plusieurs modules. Chaque projet défini ses propres paramètres. Pour un nouveau projet, il faut donc commencer par paramétrer l’environnement, ou bien importer la configuration à partir d’un autre projet. Bien que cette approche puisse être considérée comme du temps perdu dans un premier temps, elle permet finalement de mieux cloisonner les projets. Et si vous souhaitez partager une même configuration au sein d’une équipe, il existe le IntelliJ Configuration Server qui permet de centraliser et partager tout ça.

Lorsque vous lancez un processus, deux onglets apparaissent dans un même container : L’onglet Console et un onglet Debugger. Dans l’onglet Debugger, on retrouve toutes les informations et outils utiles pour débuguer : points d’arrêt, espions, threads, contexte. Lorsqu’on travaille avec plusieurs processus en parallèle, cette disposition est bien plus naturelle que celle d’Eclipse, qui a tendance à exploser les informations d’un même processus sur différentes vues, et les placer un peu partout sur l’écran.

C’est un avis personnel, mais je trouve IntelliJ IDEA plus facile d’accès, plus simple d’utilisation et finalement plus pratique.

Pourquoi pas contribuer

Il semble aussi beaucoup assez simple de contribuer à IntelliJ IDEA. L’edition Community est sur github, et il est simple de mettre en place l’environnement pour ajouter des fonctionnalités ou créer un plugin. Actuellement, je trouve un petit défaut dans le code assist par rapport à Eclipse : Lorsque qu’on commence à écrire un appel de constructeur, il n’y a pas de propositions avec les possibilités de paramètres à passer. Le code est automatiquement complété avec le constructeur par défaut, sans avoir la possibilité de choisir parmi les autres constructeurs existants. Quand j’aurai un peu de temps, j’essaierai d’implémenter cette possibilité de choix.

Github, c'est bien :)

Github, c’est bien 🙂

Ma conclusion

IntelliJ IDEA est une excellente alternative à Eclipse pour développer en Java, et le surclasse même sur l’intégration de Maven avec une vraie gestion des scopes et des classpath associés. Dans l’édition Ultimate, l’excellent support de JavaScript et Python en font un véritable IDE multi-technologie. Il est complet et intuitif, et je le recommande à tous les développeurs qui souhaitent coder dans un environnement unique leur Backend et leur Frontend. Je ferai un nouvel article dans quelques semaines, pour indiquer si j’ai persisté dans cette voie, ou si je suis finalement retourné sur Eclipse.

Et n’hésitez pas à commenter !

  • Amine

    IntelliJ IDEA est payant, Eclipse est gratuit.

    • Rémi Alvergnat

      Il reste accessible pour un développeur indépendant, mais c’est un point fort pour Eclipse c’est vrai.

      J’ai un peu oublié dans l’article, mais Eclipse dispose aussi d’un excellent éditeur graphique pour le pom, et d’un arbre de dépendance bien plus agréable que le graph fourni par IntelliJ IDEA. Surtout sur les gros projets avec de nombreuses dépendances et des conflits à résoudre manuellement.

      Merci pour le commentaire, vous êtes le premier sur ce blog, bienvenue ! 🙂

  • Bonjour,
    Serte intelliJ est payante en version ultimate mais quand on voit tous les frameworks supportés nativement ça laisse rêveur. Et l’intégration avec les SCM courants est nettement plus au point qu’Eclipse. Par contre pourquoi avoir changé le keymapping? Après un temps d’adaptation somme toute assez court on est bien plus productifs avec celui d’intelliJ (expérience perso passage de 10 ans de dev eclipse à intelliJ = 5 jours d’apprentissage des raccourcis).

    Pour du dev Android il est à noter que la version community est plus que correcte et un cran au dessus d’Eclipse.

    • Rémi Alvergnat

      Effectivement, je pas parlé des SCM, mais on est la encore une fois bien mieux qu’avec Eclipse, qui est lent et perds très facilement les pédales lorsqu’on tente d’afficher la vue Team Synchronize sur un projet avec de multiples modules.

      Pour les raccourcis, tant que j’étais en phase d’évaluation, je ne voulais pas perdre de temps à les apprendre. Mais maintenant que je commence à être vraiment convaincu, et même réticent à relancer Eclipse, je vais m’y mettre, promis 🙂

      Merci pour votre commentaire, et bienvenue sur ce nouveau blog !

  • Pingback: Objectif 30 jours - Jour 1 - Pragmasphere()