Discussion :

[Hinault Romaric]

JUnit, Jenkins et Git seraient les outils préférés des développeurs Java
Java 8 adopté par 7% de développeurs, tandis que 26% utilisent encore Java 6

L’écosystème Java dispose d’un nombre important d’outils et de piles logiciels qui sont utilisés au quotidien par les développeurs dans leurs applications.

ZeroTurnaround, une entreprise spécialisée dans le développement d’outils à destination des développeurs Java, vient de publier son rapport annuel sur les outils et technologies de développement Java.

L’étude a été menée auprès de 2 164 développeurs et révèle que 82,5% de ceux-ci utilisent le framework de test unitaire JUnit. Un nombre intéressant (70%) utilisent également le serveur d’intégration continue Jenkins, ce qui laisse présager que le projet Hudson (Jenkins est né à la suite du fork de Hudson) est désormais utilisé par peu de développeurs Java.

À côté de ces outils, on retrouve également le gestionnaire de versions Git (69%) qui est très plébiscité par les développeurs ayant participé au sondage, suivi par le Framework Hibernate (67,5%) utilisé pour la gestion de la persistance des objets et de l’outil de build des projets Java Maven (64%).

Seulement 7% de répondants utilisent la dernière version de Java SE (Java 8) publiée en mars dernier. 26% sont encore sur la version 6 de la plateforme, tandis que 65% développent leurs applications avec Java 7. En entreprise, c’est Java EE 6 (49%) qui demeure le plus utilisé.

L’environnement de développement le plus populaire chez les développeurs Java est Eclipse (48%). Les entreprises quant à elle, préfèrent la version commerciale de IntelliJ IDEA (41%) .

En ce qui concerne les langages alternatifs sur la JVM, 47% des personnes interrogées ont affirmé qu’elle aimerait apprendre Scala, suivi par Groovy (31%) et Clojure (12%).

Avec une part de 50%, le serveur d’applications Apache Tomcat domine l’écosystème Java, suivi par le serveur JBoss (16%), Ponton (12%) et GlassFish(7,4%).

La migration vers Java 8 sera la priorité numéro 1 au cours des deux prochaines années pour 35% de sociétés qui ont participé au sondage.

Source : Résultats de l’étude de ZeroTurnaround


Et vous ?

Quels outils Java utilisez-vous ? Que pensez-vous des résultats de cette étude ?

[nchal]

Je suis surpris de ne pas voir SonarQube.

[Xinu2010]

Je suis surpris de ne pas voir SonarQube.

C'est la liste des outils préférés des développeurs Java, pas des Managers

[FaridM]

Je suis surpris de ne pas voir SonarQube.

Enfaite, si on se rend sur le lien ou les infos on été prises, on peut voir que dans la catégorie "Code analysis tools", SonarQube est plus utilisé que FindBugs mais c'est dernier apparait dans le résumé.

[professeur shadoko]

ravi d'y voir Hibernate et Findbugs...
marri de voir des outils que je déteste (pour des raisons très différentes): JUnit et Maven

[Gugelhupf]

L’étude a été menée auprès de 2 164 développeurs et révèle que 82,5% de ceux-ci utilisent le framework de test unitaire JUnit.

8 personnes sur 10 font des tests unitaires ? ...
Je ne dis pas que ce n'est pas bien, mais ce taux m'a l'air trop élevé. Ce chiffre ne représenterait-t-il pas le taux d'utilisation du framework JUnit parmi l'échantillon de développeur Java qui font des tests unitaires plutôt ?

[Robin56]

ravi d'y voir Hibernate et Findbugs...
marri de voir des outils que je déteste (pour des raisons très différentes): JUnit et Maven

Peux-tu détailler ton propos, ça me rend curieux.

[professeur shadoko]

Peux-tu détailler ton propos, ça me rend curieux.

oui:
JUnit : je n'ai pas du tout la même philosophie des tests . j'ai fini par écrire mon propre outil de tests (après avoir essayé d'adapter le code de JUnit qui est épouvantablement mal documenté). Sur beaucoup de projets quand je vois des tests JUnit ça me fait tapoter le menton ( en Anglais je dirais que les programmeurs sacrifient à du "lip-service") parce que neuf fois sur dix si le programmeur a à tester mettons l'addition il fait 2+2 -> super ça fait quatre! et c'est terminé (bon c'est un début, c'est déjà bien mais c'est pas suffisant). Donc JUnit ne donne pas de bonnes habitudes (je sais que je vais à contre-courant en disant ça)
(pour un lien vers une très vieille version de mon outil qui a depuis beaucoup évolué faire recherche google "GRU testing framework")

Maven: là mon opposition est plus objective. J'ai Maven sur le dos dans un très gros projet avec plus de soixante-dix "Modules" gérés par des équipes différentes. Maven est un multiplicateur de bordel: l'idée de base est séduisante mais la moindre anomalie dans les pom conduit à des comportements totalement imprévisibles (j'ai d'amples preuves que Maven ne fonctionne pas comme il prétend le faire). Maven c'est un peu comme si tu avais un compilateur qui ne relevait pas les erreurs de syntaxe et te livrait un code binaire imprévisible. J'ai discuté avec un chef de gros projet dans une grande société de soft: eux ils ont mis Maven à la poubelle par pur désespoir (je suis triste car je ne peux pas le faire).

[Robin56]

oui:
JUnit : je n'ai pas du tout la même philosophie des tests . j'ai fini par écrire mon propre outil de tests (après avoir essayé d'adapter le code de JUnit qui est épouvantablement mal documenté). Sur beaucoup de projets quand je vois des tests JUnit ça me fait tapoter le menton ( en Anglais je dirais que les programmeurs sacrifient à du "lip-service") parce que neuf fois sur dix si le programmeur a à tester mettons l'addition il fait 2+2 -> super ça fait quatre! et c'est terminé (bon c'est un début, c'est déjà bien mais c'est pas suffisant). Donc JUnit ne donne pas de bonnes habitudes (je sais que je vais à contre-courant en disant ça)
(pour un lien vers une très vieille version de mon outil qui a depuis beaucoup évolué faire recherche google "GRU testing framework")

Je serais tenté de dire pour ma part que du moment que les utilisateurs prennent l'habitude de faire des tests unitaires, c'est déjà une bonne habitude de prise.

Maven: là mon opposition est plus objective. J'ai Maven sur le dos dans un très gros projet avec plus de soixante-dix "Modules" gérés par des équipes différentes. Maven est un multiplicateur de bordel: l'idée de base est séduisante mais la moindre anomalie dans les pom conduit à des comportements totalement imprévisibles (j'ai d'amples preuves que Maven ne fonctionne pas comme il prétend le faire). Maven c'est un peu comme si tu avais un compilateur qui ne relevait pas les erreurs de syntaxe et te livrait un code binaire imprévisible. J'ai discuté avec un chef de gros projet dans une grande société de soft: eux ils ont mis Maven à la poubelle par pur désespoir (je suis triste car je ne peux pas le faire).

J'utilise moi-même pas mal Maven au boulot sur des gros projets ou non et j'en suis satisfait pour ma part (mais je vois pourquoi tu parles des incohérences qui peuvent se passer). Si tu avais le choix, tu passerais par quoi dans ce cas ?

Pour en revenir à l'article, je suis surpris de voir Git autant utilisé et SVN pas du tout dans le classement car SVN est tout de même encore très utilisé.

[nchal]

J'utilise moi-même pas mal Maven au boulot sur des gros projets ou non et j'en suis satisfait pour ma part (mais je vois pourquoi tu parles des incohérences qui peuvent se passer). Si tu avais le choix, tu passerais par quoi dans ce cas ?

Je suis également surpris parce que des remplaçant à Maven, il n'y en a pas beaucoup. Soit tu "évolue" vers Gradle mais c'est finalement assez similaire, soit tu reviens aux sources avec Ant mais c'est compliqué pour les gros projet.

[professeur shadoko]

Je suis également surpris parce que des remplaçant à Maven, il n'y en a pas beaucoup. Soit tu "évolue" vers Gradle mais c'est finalement assez similaire, soit tu reviens aux sources avec Ant mais c'est compliqué pour les gros projet.

ben oui... moi je suis coincé mais dans le projet dont je parlais ils sont revenus à se taper du Ant "à la main"....
il faudrait que les développeurs de Maven reprenne le taureau par les cornes et changent beaucoup de choses .... Bien qu'étant très "Groovy-aque" je ne connais pas Gradle (dommage je crois plus aux configuration dynamiques que purement statiques)

[Logan Mauzaize]

ravi d'y voir Hibernate et Findbugs...
marri de voir des outils que je déteste (pour des raisons très différentes): JUnit et Maven

Lol, pour ma part je déteste Hibernate pour la même raison que tu n'aimes pas Maven ;-) Je n'ai jamais trop trifouiller Maven mais il m'a l'air affreusement simple dans l'idée. Dans quel "grande fonctionnalité" (dépendance, life cycle, etc.) de Maven tu rencontres des soucis ?
Pour ma part, j'adore l'idée d'obliger les gens à avoir une notion d'artefact et de dépôt. Autant la gestion de configuration des sources est bien admise autant pour les binaires ca l'est moins. Après peut-être qu'Ivy fait tout aussi bien le boulot ?!

Je suis également surpris parce que des remplaçant à Maven, il n'y en a pas beaucoup. Soit tu "évolue" vers Gradle mais c'est finalement assez similaire, soit tu reviens aux sources avec Ant mais c'est compliqué pour les gros projet.

A l'origine Maven n'était qu'une "surcouche" Ant. En gros, une arborescence standard avec un cycle de vie standard le tout greffer sur un nombre de "target" standards. En gros, ton POM était transformé en script Ant et Maven était fourni avec un ensemble de templates.
D'ailleurs les gros projets vivent très bien sans Maven ... Avec les tâches Ant/AntCall, les imports et les macros, tu peux faire des trucs super génériques avec Ant. Pour la gestion du cycle vie, les conditions suffisent et pour les dépendances, tu as Ivy.

[professeur shadoko]

Lol, pour ma part je déteste Hibernate pour la même raison que tu n'aimes pas Maven ;-) Je n'ai jamais trop trifouiller Maven mais il m'a l'air affreusement simple dans l'idée. Dans quel "grande fonctionnalité" (dépendance, life cycle, etc.) de Maven tu rencontres des soucis ?
Pour ma part, j'adore l'idée d'obliger les gens à avoir une notion d'artefact et de dépôt. Autant la gestion de configuration des sources est bien admise autant pour les binaires ca l'est moins. Après peut-être qu'Ivy fait tout aussi bien le boulot ?!

Pour comprendre mes soucis avec Maven: je suis en charge d'un framework fondamental sur un gros projet. ça veut dire que je fais des codes de base qui sont utilisés ensuite par des tas d'autres équipes (plus de 70 modules Maven dans le projet!).
Ce qui pose problème:
- il y a de nombreuses descriptions avec héritage, mais les équipes modifient leur pom pour leur besoins ... du coup il y a des incohérence de descriptions mais du fait de l'incroyable complexité de l'ensemble Maven ne détecte pas d'incohérence, ne nous dit rien et fait sous le manteau des tas de choses imprévisibles. C'est comme si tu avais un langage de programmation qui ne te signalait pas tes erreurs et du coup faisait des choses imprévisibles.
- quand je fais une nouvelle version de mes codes de base il faut que je teste leur effet sur des codes qui, en exploitation, dépendent d'anciennes version de mes propres codes. et là je te garantis que quand tu essaye de forcer des dépendances de manière prioritaire Maven ne fait absolument pas ce qu'il prétend faire . C'est coton: tu débugues et tu te retrouve en fait pas du tout avec les mêmes version de code .... avec des incohérences incroyables ...
Bref Maven c'est bien sur des petits projets pas trop compliqués .... mais à partir d'un certain niveau de complexité c'est planté à mort....

Pour Hibernate c'est vrai que j'aime Hibernate parce que je me limite volontairement à faire des choses très simples sans rentrer dans des détails obscurs et ziguouiguesques

[Logan Mauzaize]

Pour comprendre mes soucis avec Maven: je suis en charge d'un framework fondamental sur un gros projet. ça veut dire que je fais des codes de base qui sont utilisés ensuite par des tas d'autres équipes (plus de 70 modules Maven dans le projet!).
Ce qui pose problème:
- il y a de nombreuses descriptions avec héritage, mais les équipes modifient leur pom pour leur besoins ... du coup il y a des incohérence de descriptions mais du fait de l'incroyable complexité de l'ensemble Maven ne détecte pas d'incohérence, ne nous dit rien et fait sous le manteau des tas de choses imprévisibles. C'est comme si tu avais un langage de programmation qui ne te signalait pas tes erreurs et du coup faisait des choses imprévisibles.
- quand je fais une nouvelle version de mes codes de base il faut que je teste leur effet sur des codes qui, en exploitation, dépendent d'anciennes version de mes propres codes. et là je te garantis que quand tu essaye de forcer des dépendances de manière prioritaire Maven ne fait absolument pas ce qu'il prétend faire . C'est coton: tu débugues et tu te retrouve en fait pas du tout avec les mêmes version de code .... avec des incohérences incroyables ...
Bref Maven c'est bien sur des petits projets pas trop compliqués .... mais à partir d'un certain niveau de complexité c'est planté à mort....

Ayant aussi une grosse hiérarchie de POM bien inutiles, je n'ai rencontré aucun problème dans la gestion des dépendances ... Pour info le comportement est cohérent avec le "Effective POM" ? En général je ne regarde que celui-là quand mes dépendances deviennent un vrai foutoir.

Pour Hibernate c'est vrai que j'aime Hibernate parce que je me limite volontairement à faire des choses très simples sans rentrer dans des détails obscurs et ziguouiguesques

Faire des choses simples ... Ca sonne presque comme un doux rêve. J'ai plutôt tendance à mapper des bases Legacy ; et Hibernate n'aime pas trop. Ce qui a tendance à m'énerver c'est qu'il serait en mesure de gérer beaucoup de bizarrerie mais soit c'est volontairement pas pris en charge, soit complètement buggé et volontairement laissé ainsi.