IntelliJ IDEA domine le marché des IDE avec 62 % d’adoption chez les développeurs JVM
5 février 2020
0 minutes de lectureBienvenue dans notre rapport annuel sur l’écosystème JVM ! Ce rapport présente les résultats de la plus grande enquête annuelle sur l’écosystème JVM, menée auprès de plus de 2 000 personnes au second semestre 2019. Nous remercions toutes celles et ceux qui ont participé et partagé leurs avis sur Java et les sujets liés à la JVM.
Ce rapport se compose de six articles :
64 % des développeurs indiquent que Java 8 reste la version la plus utilisée
Kotlin dépasse Scala et Clojure et devient le 2e langage le plus populaire sur la JVM
Spring domine l’écosystème Java : 60 % l’utilisent pour leurs applications principales
IntelliJ IDEA domine le marché des IDE avec 62 % d’adoption chez les développeurs JVM
Nous proposons également un rapport PDF soigneusement conçu, qui rassemble toutes ces informations dans un document à télécharger.
Quel est le principal environnement de développement intégré (IDE) que vous utilisez ?
Les résultats du graphique ci-dessous concordent avec ceux d’autres enquêtes récentes : IntelliJ IDEA est l’IDE le plus utilisé dans la communauté JVM. Selon notre enquête, 62 % des développeurs utilisent les éditions Community et Ultimate d’IntelliJ IDEA, ce qui en fait aujourd’hui l’IDE dominant chez les développeurs JVM.
Apache NetBeans reste stable à la 3e place, avec 20 % du marché, soit à peu près les mêmes chiffres que l’an dernier. Plus bas dans le classement, on constate toutefois avec surprise que l’adoption de VS Code a à peine progressé par rapport à l’année dernière. Bien que VS Code soit considéré comme l’un des IDE préférés dans d’autres écosystèmes, il semble ne pas connaître la même popularité auprès des développeurs JVM.
En fait, VI/Vim/Emacs est même plus utilisé que VS Code. Ces résultats font émerger un groupe de développeurs qui, apparemment, n’aiment pas les IDE. S’agit-il de puristes du code ou se sentent-ils plus intelligents en tapant tout manuellement ? Dans tous les cas, nous ne jugeons pas ! :)

La popularité croissante d’IntelliJ IDEA s’explique notamment par sa longue liste de fonctionnalités intégrées et sa prise en charge native de Kotlin. Avec le recul d’Eclipse IDE, passé de 38 % l’an dernier à seulement 20 % cette année, l’écart entre IntelliJ IDEA et Eclipse IDE se creuse. Si l’on tient compte du fait qu’avant 2016 Eclipse était l’IDE le plus utilisé (d’après les résultats des rapports RebelLabs, que nous remercions), il est évident que JetBrains a bien travaillé pour améliorer son logiciel et répondre aux besoins des développeurs JVM.

Quel outil de build utilisez-vous pour votre application principale ?
Les équipes peuvent utiliser plusieurs systèmes de build pour différents projets. Pour cette question, nous avons donc autorisé une seule réponse : nous voulions connaître l’outil de build le plus utilisé par les développeurs pour leur application principale et la comparer aux données historiques (issues, là encore, des rapports précédents de RebelLabs et de Snyk) afin de dégager des tendances.

Maven reste en tête, avec deux tiers des parts et une légère progression par rapport à l’an dernier. Gradle, son dauphin, affiche le même taux de croissance que son concurrent Maven. Alors, la « guerre » entre les systèmes de build est-elle terminée ou s’agit-il simplement d’une pause ?

Avec le plugin Maven de Snyk, vous pouvez analyser votre application à chaque build pour vérifier que vous n’utilisez pas de dépendances directes ou transitives contenant des vulnérabilités connues.
Quel serveur CI utilisez-vous ?
Comme la plupart des développeurs Java s’y attendraient, Jenkins remporte la course aux serveurs CI avec une part de marché impressionnante de 58 %. Un énorme écart sépare Jenkins de l’option arrivée en deuxième position, « aucun ». Même si le nombre de personnes qui n’utilisent pas de serveur CI a nettement diminué par rapport à l’année dernière, il reste étonnamment élevé. Mais pourquoi choisir de ne pas utiliser de serveur CI ? Voilà une question intéressante à poser aux développeurs lors de prochaines enquêtes !
Les concurrents les plus proches de Jenkins sont GitLab, avec 6 %, et TeamCity, avec 5 %.

Vous pouvez détecter les vulnérabilités connues dans votre application à chaque exécution de CI en ajoutant le plugin Snyk pour Jenkins. Vous évitez ainsi d’envoyer par erreur en production du code contenant des vulnérabilités connues.
Quel dépôt de code utilisez-vous pour votre application principale ?
Il est peut-être surprenant d’apprendre que GitLab remporte cette bataille. Avec 35 % des parts de marché, il devance légèrement GitHub, en deuxième position avec 31 %. Nous remarquons également que GitLab est moins utilisé dans les dépôts publics, principalement parce que la plateforme propose depuis longtemps des dépôts privés. En outre, GitLab offre bien plus qu’un simple dépôt, notamment un pipeline CI. Toutefois, au vu des réponses à la question précédente, cela ne semble pas expliquer pourquoi les développeurs choisissent GitLab plutôt que GitHub.

Vous pouvez également intégrer l’analyse des dépendances de Snyk à votre dépôt GitHub afin que chaque pull request soit analysée et que vous ne puissiez pas introduire de nouvelles vulnérabilités connues ou de licences problématiques dans vos dépendances open source.
À quel moment analysez-vous vos dépendances à la recherche de vulnérabilités connues ?
Analyser vos dépendances à la recherche de vulnérabilités connues est la meilleure chose à faire ! Il est essentiel de savoir si le code produit par quelqu’un d’autre peut être utilisé en toute sécurité. Lorsqu’une vulnérabilité est découverte, le nombre de victimes potentielles est considérable, selon la popularité du package concerné. Si une vulnérabilité a déjà été divulguée, il y a de fortes chances qu’un correctif soit disponible dans une version plus récente du package. Toutefois, si un développeur utilise encore une ancienne version sans connaître le problème de sécurité ni son correctif, il est vulnérable sans le savoir.
Selon notre enquête, 30 % des personnes interrogées analysent leurs dépendances à la recherche de vulnérabilités connues dans le cadre du pipeline CI/CD. Utiliser ces analyses comme point de contrôle avant le déploiement en production est un bon début.
Cependant, effectuer des analyses à plusieurs étapes du développement, par exemple sur votre poste de travail (16 %) ou à la publication d’une PR (9 %), permet de détecter les problèmes plus tôt.
La découverte de problèmes à un stade avancé du cycle de développement logiciel (SDLC) entraîne souvent un important travail de reprise pour les corriger.
Cela dit, il est surprenant de constater que seules 8 % des personnes interrogées surveillent leurs applications en production. Les vulnérabilités apparaissent au fil du temps ; il est donc judicieux de surveiller régulièrement un instantané de la production. Plus inquiétant encore, 28 % des participants n’analysent pas leurs dépendances à la recherche de vulnérabilités connues. Espérons que cela s’explique par le fait que ces développeurs n’utilisent aucune dépendance dans leur application actuelle. Personne ne veut être le prochain Equifax, n’est-ce pas ?

Ce rapport ne s’arrête pas là ! Quelle section souhaitez-vous lire ensuite ?
64 % des développeurs indiquent que Java 8 reste la version la plus utilisée
Kotlin dépasse Scala et Clojure et devient le 2e langage le plus populaire sur la JVM
Spring domine l’écosystème Java : 60 % l’utilisent pour leurs applications principales
IntelliJ IDEA domine le marché des IDE avec 62 % d’adoption chez les développeurs JVM
