Il y a 10 ans -
Temps de lecture 5 minutes
Les outils du développeur web en Java
Les outils du développeur web en Java
Imaginons un développeur Java qui démarre un nouveau projet web et qui inaugure un poste de développement flambant neuf. Seul l’OS est installé, Windows, Mac OS X ou Linux, peu importe : les outils présentés dans cet article sont tous disponibles sous votre OS favori.
Pour la gestion des dépendances
Avant même de choisir un IDE, l’utilisation d’un outil de gestion de dépendances s’impose. Il s’occupera de télécharger les fichiers jar des librairies, et rend l’application déployable sur de multiples environnements (développement, production, qualification…) à partir d’une poignée de commandes standards.
Partons sur la solution la plus courante, Maven. Allons faire un tour sur mvnrepository.com pour trouver les dépendances à ajouter dans le pom.xml :
- Junit est le choix standard pour écrire les tests unitaires. Il y a aussi TestNG,
- Pour tester les classes en isolation, Mockito et EasyMock sont de bons candidats mais la syntaxe du premier est plus naturelle et moins verbeuse,
- FestAssert est une alternative moderne aux méthodes d’assertion de Junit, avec une syntaxe plus claire et une gestion des listes d’objets,
- Cobertura pour publier des rapports sur la couverture de tests,
- Le trio PMD/Findbugs/Checkstyle pour vérifier la qualité du code et publier les rapports obtenus,
- Selon certains, les classes Apache Commons devraient faire partie de l’API standard de Java. Un client HTTP dans commons-http, des librairies utilitaires pour les types standards dans commons-lang…
- CXF pour générer le client et l’implémentation des services web Soap à partir du fichier WSDL,
- Le framework Spring, en particulier pour améliorer la testabilité grâce à l’injection de dépendances.
La multitude d’archetypes disponibles pour Maven permet d’initialiser un squelette d’application en quelques secondes.
Choisir un framework web
Pour une application web, on peut lorgner sur GWT. La possibilité de développer les vues en pur Java est alléchante pour un spécialiste du langage, et ça facilitera les tests unitaires. Pour qui ne connaît pas le javascript, c’est GWT qui s’occupe de générer le code client et la partie Ajax.
GWT est très répandu, bien documenté, supporté par Google, mais il y a peu de composants graphiques en standard.
Heureusement, plusieurs dérivés de GWT proposent une bibliothèque de widgets plus aboutie :
- SmartGWT propose des composants surprenants, notamment un tableau avec du chargement à la demande et des fonctionnalités de tri « à la Excel », mais c’est surtout une boite noire qui encapsule du Javascript par du Java,
- Les widgets de Vaadin sont visuellement élégants mais moins sophistiqués, et sa démarche de construction des vues côté serveur l’éloigne du GWT standard,
- Le meilleur choix est probablement GXT : grande bibliothèque de widgets, mode de développement proche de GWT, et le code du framework est plus transparent. GXT est « mavenisé » : quelques lignes dans le fichier de configuration Maven suffisent pour profiter des nouveaux widgets.
Spring MVC constitue un autre choix intéressant, avec l’avantage de s’intégrer très facilement avec le framework Spring (le contraire serait étonnant). Les contrôleurs de Spring MVC facilitent l’implémentation de services REST, mais le choix de cette solution nécessite l’intégration d’une couche supplémentaire pour développer une interface graphique attractive, par exemple JQuery.
Sur mojo.codehaus.org, vous trouverez un archetype GWT pour Maven. Sur appfuse.org il y a un archetype d’application basée sur Spring MVC.
L’environnement de développement
Afin de commencer à coder sans payer de licence, Eclipse est le choix standard, agrémenté de quelques plugins :
- m2e pour bénéficier de Maven directement dans l’IDE,
- MoreUnit pour faciliter les tests unitaires Junit,
- EclEmma pour aller encore plus loin dans les tests, voir la couverture directement au niveau du code et favoriser le TDD,
- Google Plugin for Eclipse, pour (entre autres) debugger une application GWT en pas-à-pas avec un clic droit et un « debug as web application », au lieu de passer par les cibles maven.
Pour le développeur fortuné, Intellij IDEA est l’IDE du moment : plus performant qu’Eclipse, son ergonomie est aussi plus pragmatique, et le niveau de fonctionnalité est équivalent : intégration Maven, intégration GWT, affichage de la couverture des tests unitaires…
Si l’application doit dépendre d’un web service externe, SoapUI est une application desktop qui permet de “mocker” le service en renvoyant des réponses prédéfinies, et le package ainsi obtenu peut être déployé par Maven. Très utile pour conserver la maîtrise des dépendances dans un environnement de développement.
Les applications web pour le développement
Quand la phase de réalisation est engagée, le travail en équipe est facilité par l’utilisation d’applications web :
- Github pour partager le code source,
- Jenkins ou Teamcity pour lancer les builds Maven sur un serveur d’intégration continue. Possibilité de lancement à heure régulière ou bien en surveillant des évènements,
- JIRA pour gérer les demandes d’évolution et les anomalies,
- Gerrit pour faciliter les revues de code,
- Pivotal Tracker pour l’organisation d’une équipe de développement agile.
Pour aller plus loin
Tous ces outils constituent un socle solide, quelle que soit la plate-forme choisie, grâce à la portabilité du Java et des applications web. Bien sûr, ce socle laisse la place à tout un écosystème d’outils propre à votre OS favori…
Commentaire
17 réponses pour " Les outils du développeur web en Java "
Published by jbleduigou , Il y a 10 ans
Je suis d’accord dans l’ensemble avec les choix préconisés. Concernant apache commons on a une alternative sérieuse avec Guava. Il aurait été intéressant d’avoir une comparaison des licences pour les différentes options (je pense aux dérivés de GWT par exemple).
Published by pCla , Il y a 10 ans
L’article est intéressant, je vais prendre le temps de regarder dans le détail les petits plugins présentés.
Par contre est ce qu’il ne faudrait pas y rajouter une section bases de données (NoSQL est à la mode mais qu’est ce que ça représente en terme de mise en place d’un projet?) ? Et éventuellement une serveur d’appli non ?
Published by Arnaud , Il y a 10 ans
Quoi, on est resté en 2006 ?? ;)
Published by Anthony , Il y a 10 ans
Chez Scub, nous avons opté pour GWT-Bootstrap, après avoir testé SmartGwt ou GWT-ext (à l’époque). On souhaitait surtout avoir une sur-couche graphique élégante et facilement intégrable, sans nous proposer des composants ne répondant pas complétement à nos besoins ou qui au contraire sont trop complexes pour un besoin simple. Notre socle technique Scub Foundation est donc régulièrement enrichi avec les nouveaux composants que nous développons et qui s’appuie sur GWT-Bootstrap.
Published by Christophe Pelé , Il y a 10 ans
@pCla @jbleduigou Cet article a été écrit avec une contrainte de place pour paraître dans le magazine Programmez, il aurait effectivement été intéressant d’approfondir certains sujets.
@Arnaud Oui, ces outils existent depuis belle lurette. Ce qui est bon signe :)
Published by Oliv , Il y a 10 ans
@Christophe Pelé Bon ou mauvais signe c’est binaire. Gardé un outils qui devient vieux alors que d’autres créés n’arrêtent pas d’améliorer nos conditions à choisir je sais celui que je prends.
Published by Benoit , Il y a 10 ans
Je ne suis pas vraiment convaincu par le choix du framework quand même ! Pour le reste, c’est un article clair et concis ;)
Published by Adrien , Il y a 10 ans
Habitué à suivre le blog Xebia, avec cet article je reste un peu sur ma faim. Il manque dans l’article quelques justifications ou la description des contraintes projets qui justifieront probablement ces choix.
J’ajouterai une partie sur les outils coté client:
Navigateurs, outils de debug built-in, plugins : firebug, valideur w3c, selenium ?
Le choix de GWT parait arbitraire, on aurait pu l’opposer à JSF + bibliothèques de widget ( myfaces, primefaces, Vaadin). Entre nous, un développeur web qui ne connait pas JavaScript, devrait commencer à s’y intéresser vu l’effervescence autour de ce langage.
Certaines bibliothèques Apache Commons sont devenus obsolètes et sont peu performantes ( par exemple commons-collections), préférer Guava dont une partie sera intégrée au JDK.
Pourquoi pas utiliser l’outil wsimport et le plugin maven jaxws au lieu de CXF?
A cette liste déjà pas mal exhaustive, il faut ajouter un JDK et un serveur d’appli, et on pourra enfin coder notre hello world.
Published by Olivier , Il y a 10 ans
Eclipse ? Pour moi il est totalement largué (j’avoue j’ai pas testé Kepler mais bon…) Trop lourd, trop lent, n’utilise pas Maven de manière native (m2e est une surcouche qui fait sa propre sauce, mais qui n’appelle pas directement les instructions mvn), intégration JEE/HTML5 très moyenne et pire que tout WTP n’a jamais réussi a être vraiment stable et performant.
Je lui préfère 100 fois Netbeans. La version 7.3+ est bluffante. Le projet Easel qui permet de déployer en live du code HTML5 (pas besoin de rafraichir dans le navigateur…) et surtout de débugger dans l’IDE du JS est pour moi indispensable à l’époque de l’essor des solutions HTML5/JS/CSS3. Je n’ai jamais vu l’intégration avec les serveurs d’applis planter (contrairement au WTP) et l’intégration avec Maven se fait sans surcouche, donc sans surprise (j’ai déjà vu plusieurs projets pour lesquels les résultats d’exécution étaient différents entre mvn et m2e).
GWT + Spring ? Aujourd’hui je partirai volontiers sur un bon gros standard : JEE7 (ce qui peut aussi nous affranchir de CXF bien que ce ne soit pas un mal de l’utiliser ;)). Auquel j’ajouterai un petit AngularJS. Une appli découpée en module. Chaque module codé avec AngularJS et délivré par JSF2.2 par exemple.
Juste un oubli sur la façade de logging : SLF4J & Logback, incontournable aujourd’hui !
Published by Gengis , Il y a 10 ans
Bonjour,
Article intéressant, qui se prêterait à des variantes…
J’ai développé de nombreux projets « traditionnels » avec +/- l’environnement décrit (sauf GWT).
Là j’en développe un pour ma propre boite donc je suis tenu par aucune contrainte. Et l’environnement c’est :
Pour la partie serveur : scala, spring, atmosphere (websocket), sdk aws (pour dynamoDB), intellij, maven
Pour la partie client : html/css/js, angularjs, webstorm, spar (un assembleur js css). Et encore j’aurai pu remplacer html/css/js par jade/less/coffee
Ce que je veux dire par là, c’est que ca dépend du contexte, et que les choix peuvent être diamètralement opposés selon qu’il faille tenir compte de l’existant (choix d’architecture, compétences des équipes) ou pas. Ainsi une jeune boite qui développe un logiciel sans avoir de ‘compte à rendre’ à personne.
Pour Spring / Java EE : je trouve que Java EE est parfaitement adapté à des devs classiques (applications de gestion) qui peuvent se satisfaire d’une spec pondue il y a 4 ans et dont aucune des api n’est mauvaise. Le serveur d’application n’est plus « l’ennemi » et fournit toute l’infrastructure nécessaire en 1 seule fois (broker jms, web container, transactions, remoting, etc…). Et juste javaee-api à mettre dans le POM.
Spring de son côté n’a besoin de consensus pour évoluer, ce qui permet d’être en phase avec les nouveaux besoins. Par exemple, où sont les équivalents de Spring data et spring social en java ee ? Tout le monde n’en a pas besoin mais c’est là où je voulais en venir. Tout l’intérêt de la discussion java ee vs spring est de savoir dans quel contexte l’un est plus adapté que l’autre.
Published by Tibo , Il y a 10 ans
SVP dites moi que cet article date de 2006!
Eclipse : en complete perte de vitesse, Intellij IDEA est loin devant et Netbeans devient une alternative de plus en plus credible. Si Google abandonne Eclipse pour andoid, ce n’est pas un hasard…
GWT et Spring: Ca fait 5 ans que Java EE a ratrappe son retard. A moins d’une problematique particuliere, ca devrait etre l’option Java web par defaut.
Maven: Gradle est maintenant un produit mature pour moi bien plus puissant. Maven est a la traine!
Pour moi un nouveau projet c’est l’occasion de ratraper son retard sur les technos…
Published by Christophe Pelé , Il y a 10 ans
@Tibo
J’ai encore à tester Netbeans, mais les outils de développement web d’IDEA nécessitent une version propriétaire du logiciel.
Eclipse reste donc le choix de certains développeurs qui privilégient l’open-source.
Published by Mathieu , Il y a 10 ans
Je souhaite tordre le cou à cet a-priori : IntelliJ a bien une version gratuite ! La version community qui est plus agréable à utiliser qu’Eclipse.
Pour le reste on a l’air ici de s’adresser à un développeur qui ne connaîtrait que java et absolument rien d’autre, et qui n’a malheureusement pas l’air de vouloir s’intéresser à autre chose (à part ‘faire du web’). Dans ce cas pourquoi ne pas proposer Play ? Ce pauvre dev ne voulant pas trop apprendre y trouvera tout ce dont il devrait avoir besoin ?
Soit, cela ne répond pas à la question de ‘faire une application lourde dans un navigateur’, je vous l’accorde :-)
Published by Charlie Mordant , Il y a 9 ans
Il y a énormément de Stacks viables sur le marché, c’est pour cela qu’il y en a autant!
Pourquoi privilégier Spring/GWT? Il y a aussi Eclipse RAP en full Java, ou encore du portail avec Liferay, ou JEE/JSF…
Personnellement, pour du web j’utilise de l’OSGI avec Karaf, Camel, ActiveMQ Stomp/WebSocket et Angular, ce qui n’est pas mauvais non plus.
Tout dépend de la taille, du besoin des préférences, c’est pourquoi cet article n’a pas de sens (à mon sens).
Published by Saad EL Khlifi , Il y a 9 ans
Très bon rappel sur des outils et Frameworks puissants de création d’application web. Que je dirais, malgré que certains d’entre eux datent de 2006, malheureusement, ce qu’on voit, beaucoup de développeurs voir des experts, avec des années d’expériences, ignorent leurs bonne utilisation (voir leurs existence, oui ça existe :-s et en 2013)
Merci Christophe
Published by Soufiane Ghenimi , Il y a 9 ans
L’article a un bon sens objectif, c’est celui du développement des applications d’entreprise. Il y avait quoi depuis 2006? il y a des outils et des APIs qui s’apparaissent mais aussi d’autres qui s’améliorent! Restez en veille et gardez vos outils!
Published by Anas , Il y a 8 ans
Le meilleur outil est celui qu’on maîtrise.
Quid de comment faire cohabiter une équipe de dev avec des IDE différents par développeur ?
ça ce serait une bonne avancée pour l’industrialisation des dev.