Discussion :

[Hinault Romaric]

Êtes-vous satisfait de l’environnement Eclipse ?
Une enquête montre une baisse de la satisfaction des utilisateurs de l’EDI

C’est devenu une tradition pour la communauté Eclipse. Depuis 2009, une enquête annuelle est soumise à la communauté des utilisateurs de l’environnement de développement open source.

L’enquête de cette année montre une baisse de la satisfaction des développeurs qui utilisent l’EDI. En 2012, 90% de développeurs interrogés avaient affirmé être satisfaits d’Eclipse. Ce nombre est passé à environ 80% en 2014.

L’étude montre une adoption rapide des dernières versions d’Eclipse. Eclipse 4.4 Luna, sorti il y a moins d’un mois, a déjà été adopté par 10,2% des développeurs. La version la plus utilisée est Eclipse 4.3 Kepler (66,8%).

Java 8 a été adopté par 9,2% de développeurs utilisant Eclipse. 59,2% utilisent encore Java 7 et environ ¼ ont encore recours à Java 6 et versions antérieures pour coder.

Git s’est imposé comme gestionnaire de versions devant Subversion. 33,3% de développeurs ont affirmé qu’ils utilisent Git, contre 30,7% pour Subversion, qui perd des utilisateurs au fil des ans.

Pour les build, Maven et Jenkins continuent à être les outils les plus utilisés par les développeurs. Gradle gagne cependant de plus en plus en popularité. Sa part est passée de 4,5% en 2013 à 11% en 2014.

Du côté des serveurs d’applications, Tomcat mène le peloton de tête (32,6%), suivi de JBoss (11,8%) et Jetty(7,2%).

Eclipse étant un environnement principalement destiné aux développeurs Java, il n’est pas surprenant que celui-ci soit le langage principal des personnes ayant participé au sondage (78,7%). Toutefois, un grand nombre utilise également JavaScript (56%).

La mouvance de l’internet des objets touche également les développeurs qui utilisent Eclipse, dont 35,7 ont affirmé qu’ils utilisent leur temps personnel à la découverte de BeagleBone, Arduino et Raspberry Pi.

L’enquête « Eclipse Community » a été menée auprès de 876 développeurs à travers le monde.


Source : Résultats de l'etude


Et vous ?

Qu’en pensez-vous ? Etes-vous satisfait de l’EDI Eclipse et de ses évolutions ? Pourquoi ?

Quelle version utilisez-vous ? Avez-vous adopté la dernière version ?

[spidetra]

Salut,
La variation de satisfaction de 90% à 80% a eue lieu entre 2012 et 2013.
Entre 2013 et 2014, le niveau de satisfaction est stable : 80%.
Source : Eclipse Community Survey 2013


--
Philippe

[flow10000]

Maintenant que j'ai 8Go de mémoire sur ma machine, je suis assez satisfait de l'environnement Eclipse.

[Grimly]

L'utilisation d'un IDE ou d'un autre est une question d'habitude.

J'essaie de ne pas imposer d'IDE à mes collègues et de les aider à trouver les outils équivalents, mais certains chefs de projets demandent carrément de changer l'IDE pour "aller plus vite", sauf qu'ils en oublient le temps de prise en main. Utiliser un outil spécifique à un IDE est une aberration, l'IDE n'est pas livré avec le programme livré que je sache, coder sur un bloc note devrait être possible (fastidieux mais possible).

Eclipse est un bon IDE, il manque de quelques outils en JS et PHP que je retrouve avec Netbeans, mais sur des projets Java, je n'ai pas encore eu de cas où une de ses fonctionnalités était mieux faite sur un IDE que sur l'autre (IntelliJ compris).

[Vlozer]

C'est un peu foireux les stat basées exclusivement sur ceux qui utilisent encore l'IDE, les gens qu'ils l'aiment pas sont deja sur IntelliJ ou NetBean...
C'est pour ces meme raisons que la team android reste persuadé que le Java est un choix qui convient à tout le monde, car ils sont plus souvent confronté à des ingénieurs purement java qu'à des gens qui passent par xamarin/Qt ou qui utilisent du Scala...

[Potomac]

j'utilise eclipse depuis plus de 10 ans, j'apprécie la possibilité d'utiliser cet EDI avec des tas de langages différents grâce aux plugs-in, les habitudes ont été prises donc j'aurai du mal à l'abandonner,

j'utilise bien sûr la dernière version Luna ( je suis sur une distribution linux rolling release avec archlinux ),

le seul bémol c'est le démarrage un poil long si on a beaucoup de plug-in,

mais je pense qu'avec une machine récente et un SSD ça doit très bien tourner

[Zefling]

L'utilisation d'un IDE ou d'un autre est une question d'habitude.

J'essaie de ne pas imposer d'IDE à mes collègues et de les aider à trouver les outils équivalents, mais certains chefs de projets demandent carrément de changer l'IDE pour "aller plus vite", sauf qu'ils en oublient le temps de prise en main. Utiliser un outil spécifique à un IDE est une aberration, l'IDE n'est pas livré avec le programme livré que je sache, coder sur un bloc note devrait être possible (fastidieux mais possible).

Eclipse est un bon IDE, il manque de quelques outils en JS et PHP que je retrouve avec Netbeans, mais sur des projets Java, je n'ai pas encore eu de cas où une de ses fonctionnalités était mieux faite sur un IDE que sur l'autre (IntelliJ compris).

Je suis habitué à Eclispe (pour PHP et Java). Dans ma nouvelle boîte, c'est NetBeans (pour Java) qui est imposé et franchement j'ai souvent du mal à y retrouver mes petits... Avec l'habitude de faire des choses qui ne sont pas possibles comme dans Eclipse, je ne perds pas mal de temps. Mais ça me force aussi à gratter un peu pour voir que l'on peut faire avec. Pour l'instant, j'ai une préférence pour Eclipse, mais NetBeans est pas mal pour certains trucs... Pour l'instant, ce que je constate c'est que l'un comme l'autre n’est pas l'outil idéal (que je n'ai toujours pas trouvé ^^) dont je rêverais.

Tout ce que je peux dire, c'est que pour Eclipse, depuis le temps que je l'utilise, il s'améliore au fil du temps. Peut-être pas assez vite pour moi... La force de l'habitude est forte et aller voir ailleurs prendre du temps qu'on n’a pas toujours envie de prendre.

[ArnaudMorisset]

Après avoir utilisé Eclipse JUNO pour faire un peu de tout, j'utilise maintenant Eclipse LUNA JavaEE édition et ça me convient parfaitement pas de soucis de "Lourdeur" vu qu'il n'est pas bourré de plugins

[reviretan]

J'ai jamais accroché à cet ide. C'est lent, il faut faire des tonnes de manips avant même de pouvoir l'utiliser, ergoniquement c'est mal foutu, ok s'y retrouve pas.

Ensuite, a ma connaissance eclipse est le seul ide que je connaisse qui créé des dépendances aux projets développés dessus (les projets jee, la structure du projet non standard).

Le fait que eclipse gueule parce qu'il y a des erreurs ds le code, alors qu'il n'y en a aucune.

L'interface des années 80.

Des messages d'erreurs tout le temps, sans aucun sens.

Bref pour toutes ces raisons, j'ai jamais réussi à developper plus de qq jours sur cet ide. Et je ne comprends pas (hormis à cause des habitudes) pourquoi il est autant répandu en entreprise.

Je précise que mon utilisation a tjs été tres basique. Je n'installais aucun plugin particulier. Ah aussi je me rappelle, avant meme de pouvoir l'utiliser, je me suis chopé plusieurs fois des exceptions des le premier démarrage. Fallait changer qq chose dans le fichier ini. Une vaste blague cet ide...

[Invité]

L’enquête « Eclipse Community » a été menée auprès de 876 développeurs à travers le monde.

Outre mon avis personnel à propos de l'IDE, je trouve que 876 personnes, c'est très peu pour un IDE de cette envergure ... Il semble très répandu comme IDE (perso, j'accroche pas du tout, je préfère de loin IntelliJ), je reste étonné que si peu de personnes aient voté ...

[Laurent.B]

Maintenant que j'ai 8Go de mémoire sur ma machine, je suis assez satisfait de l'environnement Eclipse.

C'est clair qu'il n'est pas économe dans ce domaine mais les autres IDE sont-il mieux lotis par rapport à ça ? Par exemple JDeveloper est encore plus gourmand mais c'est normal, il est plein d'assistants et d'outils graphiques, donc ça ne peut pas être sans conséquence.

J'essaie de ne pas imposer d'IDE à mes collègues et de les aider à trouver les outils équivalents, mais certains chefs de projets demandent carrément de changer l'IDE pour "aller plus vite", sauf qu'ils en oublient le temps de prise en main. Utiliser un outil spécifique à un IDE est une aberration, l'IDE n'est pas livré avec le programme livré que je sache, coder sur un bloc note devrait être possible (fastidieux mais possible).

Personnellement, je pense qu'il est déjà assez compliqué de gérer les problèmes d'un seul IDE avec tous les plugins nécessaires, pour éviter de s'embêter en plus avec différents IDE... Ca me paraît peu recommandable comme situation. Ca dépend évidemment de que l'on fait avec mais bon, pour la pérennité des développements et l'efficacité, laisser champ libre aux souhaits de chacun, introduit des complications. Imposer un IDE peut contrarier les plus psychorigides mais si le choix de celui-ci est le plus cohérent possible, globalement ça doit être préférable. Bon, la cohabitation n'est pas intrinsèquement interdite donc tout va bien. Mais basculer d'un IDE à un autre, c'est clair que ça a un coût, dont il vaut mieux tenir compte.

Eclipse est un bon IDE, il manque de quelques outils en JS.

Je ne saurais le comparer à ce niveau-là à NetBeans mais il y a ce qu'il faut pour JS, au pire on trouve des plugins complémentaires. Donc, qu'est-ce qui lui manque selon toi ?

J'ai jamais accroché à cet ide. C'est lent, il faut faire des tonnes de manips avant même de pouvoir l'utiliser, ergoniquement c'est mal foutu, ok s'y retrouve pas.

Tout changement d'IDE comporte un temps d'adaptation et d'apprentissage... Personnellement, je ne vois rien de très gênant au niveau de l'ergonomie (même s'il n'est pas parfait) et dire qu'il est lent est plutôt juste mais tout ça évolue tu sais.

Ensuite, a ma connaissance eclipse est le seul ide que je connaisse qui créé des dépendances aux projets développés dessus (les projets jee, la structure du projet non standard).

Peux-tu être plus clair ? Quel est le problème ?

Le fait que eclipse gueule parce qu'il y a des erreurs ds le code, alors qu'il n'y en a aucune.

Oui, c'est bien connu, Eclipse invente des erreurs... A mon avis quand tu as eu ce genre de problème, tu n'a pas assez creusé la question de savoir pourquoi c'était le cas. Ca peut aussi bien être de ta faute qu'être un bug mais globalement, personnellement je lui fais confiance à ce niveau-là, s'il relève une erreur, c'est qu'il y a vraiment un problème quelque part.

L'interface des années 80.

Par très précis comme remarque... Si c'est une histoire de look, ce n'est effectivement pas au goût du jour mais personnellement ce n'est pas ce que je demande à l'IDE. Pour le reste, il évolue...

Des messages d'erreurs tout le temps, sans aucun sens.

Là par contre, j'aurais du mal à te contredire. De ce côté-là je sais plus ou moins pourquoi c'est ainsi mais il est clair que ça n'est pas très propre et que ça peut effrayer certains.

Et je ne comprends pas (hormis à cause des habitudes) pourquoi il est autant répandu en entreprise.

Ca par contre c'est simple. Il est répandu parce qu'il n'est pas lié à un éditeur en particulier, il est Open Source, il constitue avant tout une plate-forme servant de base à beaucoup d'autres logiciels, il a une grosse communauté, il est intrinsèquement très évolutif et multi OS...

je me rappelle, avant meme de pouvoir l'utiliser, je me suis chopé plusieurs fois des exceptions des le premier démarrage. Fallait changer qq chose dans le fichier ini. Une vaste blague cet ide...

En fait tu oublies un détail, c'est qu'Eclipse ne s'installe pas et cela est voulu car ça permet d'éviter au maximum les dépendances avec les OS. L'inconvénient effectivement, c'est qu'il est souvent nécessaire de finaliser son installation à la main... De nos jour c'est très limite comme façon de faire, surtout si au premier lancement on obtient une erreur qui ne nous dit même pas ce qu'on doit faire. Pour donner une première mauvaise impression, il n'y a pas mieux. D'autant que ça n'arrive pas à tout le monde, puisque si le bon JRE ou JDK est déjà installé et qu'Eclipse arrive à le trouver sans problème, le lancement s'exécute normalement...

Loin d'être parfait, Eclipse est aussi loin d'être une vaste blague... sans quoi il n'y aurait pas autant d'adeptes.

[Invité]

Personnellement Eclipse me suffit largement pour ce dont j'ai besoin (Développement Java, Subversion, ...), et puis si j'ai besoin d'ajouter de nouvelles fonctionnalités, les plugins suffisent (si j'en trouve ^^).

Je le trouve aussi plus simple à l'utilisation que Netbeans, et son interface me plait beaucoup (j'utilise la version Kepler). Mais ce que j'apprecie surtout, c'est tout ce concerne le développement sur Android. Quand j'ai essayé d'installer le plugin sur Netbeans, j'ai failli casser mon ordinateur .

[ymajoros]

Personnellement, je pense qu'il est déjà assez compliqué de gérer les problèmes d'un seul IDE avec tous les plugins nécessaires, pour éviter de s'embêter en plus avec différents IDE... Ca me paraît peu recommandable comme situation. Ca dépend évidemment de que l'on fait avec mais bon, pour la pérennité des développements et l'efficacité, laisser champ libre aux souhaits de chacun, introduit des complications. Imposer un IDE peut contrarier les plus psychorigides mais si le choix de celui-ci est le plus cohérent possible, globalement ça doit être préférable. Bon, la cohabitation n'est pas intrinsèquement interdite donc tout va bien. Mais basculer d'un IDE à un autre, c'est clair que ça a un coût, dont il vaut mieux tenir compte.

Pourquoi gérer les problèmes d'IDE ? En laissant la liberté à chaque développeur, et en ciblant une plateforme et ses bonnes pratiques (JDK + outil de build) plutôt qu'un IDE, tout le monde est content. Par ex : si on se centre sur Maven, chacun peut utiliser son IDE. Personne n'a à basculer, chacun travaille le code avec ses outils. Et c'est beaucoup plus proche du build de l'intégration continue, par exemple.

Ça n'empêche même pas de stocker le .project si nécessaire pour contenter les utilisateurs d'Eclipse, par exemple.

[Laurent.B]

Pourquoi gérer les problèmes d'IDE ? En laissant la liberté à chaque développeur, et en ciblant une plateforme et ses bonnes pratiques (JDK + outil de build) plutôt qu'un IDE, tout le monde est content. Par ex : si on se centre sur Maven, chacun peut utiliser son IDE. Personne n'a à basculer, chacun travaille le code avec ses outils. Et c'est beaucoup plus proche du build de l'intégration continue, par exemple.

Ça n'empêche même pas de stocker le .project si nécessaire pour contenter les utilisateurs d'Eclipse, par exemple.

Hé bien tu dis exactement la même chose que moi mais à une échelle plus restreinte, tu forces les gens à utiliser Maven. Quelle idée, pourquoi ne pas laisser chacun se débrouiller avec ses outils de prédilection, du moment que le résultat du build est conforme à ce que l'on veut ? Je grossis à peine le trait.

Mais si on n'est pas d'accord, c'est sans doute parce qu'on n'a pas travaillé dans les mêmes environnements. De ma constatation, plus les équipes sont grosses, plus les règles sont strictes à tous les niveaux. Déléguer le choix des outils aux développeurs introduit des risques et complique les procédures en tout genre, lesquelles sont justement là pour homogénéiser l'ensemble et faire en sorte d'écarter le maximum de risques, du fait que l'un a utilisé tel outil et l'autre pas... Par exemple, rien que le formatage du code source, si tu n'utilises pas le même éditeur avec les mêmes possibilités de réglage, tu as toutes les chances de te rendre la vie plus compliquée au moment de comparer des versions d'un même fichier. Ce n'est qu'un petit exemple parmi d'autres mais c'est en cela qu'il est préférable d'avoir un socle le plus commun possible, de façon à ne pas être pollué par les particularités de chaque environnement.

Voilà bon, faire ce genre de choix dépend de beaucoup de facteurs évidemment, il vaut mieux bien peser le pour et le contre mais globalement, la rationalisation reste un facteur de qualité.

[ymajoros]

Hé bien tu dis exactement la même chose que moi mais à une échelle plus restreinte, tu forces les gens à utiliser Maven. Quelle idée, pourquoi ne pas laisser chacun se débrouiller avec ses outils de prédilection, du moment que le résultat du build est conforme à ce que l'on veut ? Je grossis à peine le trait.

Mais si on n'est pas d'accord, c'est sans doute parce qu'on n'a pas travaillé dans les mêmes environnements. De ma constatation, plus les équipes sont grosses, plus les règles sont strictes à tous les niveaux. Déléguer le choix des outils aux développeurs introduit des risques et complique les procédures en tout genre, lesquelles sont justement là pour homogénéiser l'ensemble et faire en sorte d'écarter le maximum de risques, du fait que l'un a utilisé tel outil et l'autre pas... Par exemple, rien que le formatage du code source, si tu n'utilises pas le même éditeur avec les mêmes possibilités de réglage, tu as toutes les chances de te rendre la vie plus compliquée au moment de comparer des versions d'un même fichier. Ce n'est qu'un petit exemple parmi d'autres mais c'est en cela qu'il est préférable d'avoir un socle le plus commun possible, de façon à ne pas être pollué par les particularités de chaque environnement.

Voilà bon, faire ce genre de choix dépend de beaucoup de facteurs évidemment, il vaut mieux bien peser le pour et le contre mais globalement, la rationalisation reste un facteur de qualité.

Oui, enfin il faut bien choisir ce qui est commun à un niveau ou un autre. Le mettre au niveau des sources et du build me semble raisonnable : on convient de technos (par ex. java, java ee, maven...). Le mettre au niveau de l'IDE n'apporte aucune plus-value. Au contraire, ça rigidifie le projet.

J'ai bossé dans des petits projets rigides, dans des gros rigides et de gros projets plus souples (je dirais même "agiles", c'est finalement un état d'esprit général). Ce n'est pas la taille du projet qui fait la différence. Et vraiment, la qualité finale est bien meilleure dans les projets souples sur les outils mais stricts sur les règles de base. C'est un compromis entre règles et libertés. Les règles de base étant appliquées strictement, mais ouvertes à l'évolution.

Honnêtement, je n'ai jamais vu qu'imposer un IDE améliorait le projet, même pas la vélocité. Par contre, imposer que le projet fonctionne sur plusieurs IDE et ne soit pas bridé pour l'un ou l'autre améliore à terme sa qualité.

Par contre, ça impose aussi de faire le tri entre les règles importantes et celles qui ne le sont pas vraiment. Des règles trop rigides sur les espaces et un outil de diff ou de code review qui les affiche tous en rouge, par exemple, ne permettent pas d'avancer. Mais c'est en général facile à régler définitivement, en laissant tomber quelques coupages de cheveux en 4 qui n'apportent rien au projet.

[koyosama]

Il y a 5 ans, je l'ai utilise. Il avait l'air sympa.
Maintenant, j'ai l'impression qu'il a pas changer d'un pousse. Toujours le même graphisme dégueulasse.

Y' a plein de fonctionnalité, mais juste son utilisation cela devient lourd. Je préfère largement utiliser les produits de jetbrains.

Sans compter que je ne suis pas trop fan d'un IDE blanc. Il aura fallu la dernière version pour l'avoir en noir.

[redcurve]

Eclipse franchement s'est le pire IDE qui existe, quand je vois des personnes recommander d'acheter un SSD pour faire tourner un IDE il y a un problème et un gros, à la prochaine version il faudra un ordi bi-cpu avec 32go de ram et un raid 10 de SSD pour le faire fonctionner à peut près rapidement (le mieux étant de disposer d'un super calculateur juste pour ça).

Les trucs qui ne vont pas :

1. Interface ignoble
2. Trop de fouillis
3. L'IntelliSense (j'ai oublié le nom sous eclipse) est plus que lent
4. Lenteur à démarrer
5. Crée des dépendances à lui même
6. Le debugger est juste horrible
7. Malheureusement il est codé en java (java et les appli graphique ...)

Les plus :

1. Il y plein de plugins.

Evolution :

1. Refaire le tout avec QT

[Mickael_Istria]

Interface ignoble, Trop de fouillis

Tu peux preciser?

L'IntelliSense (j'ai oublié le nom sous eclipse) est plus que lent

Quels types de projets? Quels langages? Comme dit plus haut, ceci est configurable.

Crée des dépendances à lui même

Je suis pas sur de comprendre ce point. Tu peux preciser?

Le debugger est juste horrible

Quels types de projets? Quels langages? Tu peux preciser?
C'est la premiere fois que je lis une critique concernant le debuggeur, je suis curieux!

Malheureusement il est codé en java (java et les appli graphique ...)

Mieux vaut en rester aux discussions fonctionnels. On ne va pas troller sur les choix d'architecture qui sont un peu hors-sujet.

[landry161]

Eclipse franchement s'est le pire IDE qui existe, quand je vois des personnes recommander d'acheter un SSD pour faire tourner un IDE il y a un problème et un gros, à la prochaine version il faudra un ordi bi-cpu avec 32go de ram et un raid 10 de SSD pour le faire fonctionner à peut près rapidement (le mieux étant de disposer d'un super calculateur juste pour ça).

Les trucs qui ne vont pas :

1. Interface ignoble
2. Trop de fouillis
3. L'IntelliSense (j'ai oublié le nom sous eclipse) est plus que lent
4. Lenteur à démarrer
5. Crée des dépendances à lui même
6. Le debugger est juste horrible
7. Malheureusement il est codé en java (java et les appli graphique ...)

Les plus :

1. Il y plein de plugins.

Evolution :

1. Refaire le tout avec QT

Tout à fait d'accord avec toi

[Mickael_Istria]

@Tcharl: pour le js, jsdt seul n'est en effet pas fou. Quand tu dis "rien a part changer l'icone", ce n'est pas juste par contre: j'ai de la validation a la volee, de la completion... Ca ressemble plutot a un souci dans ta conf.
Pour les features, il y a des extensions interessantes a jsdt sur MarketPlace: tern, angular...
Pour le JEE, peux-tu donner des details? Et pour m2e aussi? Idealement en reportant les cas d'erreurs et les suggestions sur bugs.eclipse.org.
Pareil pour EGit.

Et t'as essaye JBoss Tools? Ca semble correspondre pour beaucoup a ce dont tu aurais besoin pour tes devs du soir: JEE, extensions a JSDT, connecteurs m2e/jee qui vont bien..