Java est-il vraiment adapté au développement d'applications Web?

Drôle de question de la part d'un committer Apache Cocoon et Apache Wicket: tous deux sont écrits en Java et offrent une API Java pour le développement d'applications web. Mais prêtons-nous au jeu après plus de six ans de J2EE, quels-sont vraiment les points forts de Java pour le développement d'applications Web?

• Les Threads et autre TimerTask sont bien utiles (si on compare avec PHP)


• L'outillage (Eclipse JDT, JUnit) est très "pro", on oublie vite l'éditeur de texte et la ligne de commande


• Certains très bons programmes n'existent qu'en Java: Lucene, FOP


• sûrement d'autres avantages que j'ai oubliés?

En revanche l'approche Java a aussi ses inconvénients:

• l'approche tout-objet multiplie le nombre de classes et augmente le volume global et la complexité structurelle de l'application: l'outil de build (Ant ou Maven) est devenu quasiment obligatoire, même si les développements réalisés ne justifient pas cette complexité.


• Java n'est pas Open-Source, cela a deux principaux inconvénients: pendant longtemps il a été difficile d'intégrer Java avec les différents systèmes d'exploitation. D'autre part, la mise en place d'un réseau de distribution de composants a beaucoup tardé, et n'a pas été initiée par les concepteurs de Java. Face à la «complexité obscure» de Maven, on ne peut qu'envier à Perl la simplicité de son CPAN, à PHP son PEAR et à Ruby ses Gems.


• Java ne s'intègre pas avec le serveur web Apache directement, on doit maintenir un serveur séparé qui tourne sur une JVM (ceci dit Ruby on Rails semble vouloir faire de même)


• cycle de développement plus lourd, le bon vieux save+refresh ne fonctionne pas avec Java et ne peut pas être implémenté simplement et de manière fiable (JavaRebel semble cependant gagner en popularité en ce moment). Un certain nombre de frameworks écrivent des classloaders pour compiler ou recharger les classes à la volée, mais c'est loin d'être une science exacte.

D'autre part les frameworks MVC comme Apache Wicket sont très sophistiqués et très séduisants pour le développeur (l'API est proche de Swing) mais posent problème pour les applications Web 2.0:

• l'approche tout-composant éloigne de plus en plus le développeur de la problématique initiale: le serveur doit fournir au client le morceau de HTML ou de Javascript nécessaire au bon moment. Le framework devient alors un obstacle à contourner, ce qui peut se révéler difficile et fragile.


• Les fonctionnalités Ajax sont implémentées de manière très abstraite, et la réponse est enveloppée dans du XML. Pourquoi ne pas plutôt renvoyer uniquement du code JavaScript directement interprété (JSON)?


• Le modèle MVC ne se marie pas toujours très bien avec les contraintes actuelles du développement Web: JavaScript sur les navigateurs n'est pas assez standardisé et formalisé pour pouvoir bâtir des applications web par composants. Les étapes de chargements des éléments de la page par exemple sont difficilement modélisables avec une API.

S'il se prête moins à la réalisation d'applications Web, surtout les
applications Web appellées «2.0» où l'utilisateur interagit avec le
serveur de manière beaucoup plus fine que sur des applications web
classiques qui se contentent de servir des pages, l'environnement Java reste particulièrement intéressant pour une équipe de développement qui construit des bibliothèques de composants comportant des traitements métiers complexes, accessibles par exemple à travers une API Rest.

Cependant, même si on le cantonne au backend, la JVM prend du retard sur ses concurrents, et du fait de son aspect «fermé», Java n'obtient pas nécessairement les contributions qui permettraient de moderniser lae language. Ses concurrents Stackless Python, Erlang et Scala suivent la tendance actuelle de distribuer les applications sur plusieurs serveurs et de profiter du nombre croissant de processeurs. Tirer intelligemment profit de la puissance de traitement des clusters de machine, c'est le challenge à relever pour les applications Web d'aujourd'hui.

Pourquoi Java est-il donc si populaire dans le monde des services informatiques? Il répond à une demande forte de la part des professionnels, et l'ensemble de la filière s'adapte à cette demande. Java est devenue la référence commune admise dans le monde des grandes entreprises, la technologie «politiquement correcte» dans laquelle on peut s'engager les yeux fermés. Bien souvent la montée en charge n'est pas une problématique exprimée initialement. L'exercice d'optimisation a posteriori est donc bien souvent fastidieux. Avec Java il est tellement facile de construire des cathédrales, en réutilisant des librairies par ci par là, que le développeur (ou même l'architecte) oublie bien souvent l'aspect efficacité au profit des fonctionnalités.

Par contre quand on a la liberté de créer une application web en dehors de ce monde corporate, on aura intérêt à utiliser des technologies plus «abordables» pour rester dans la course: abordables en termes de développement, qui n'a pas eu régulièrement des problèmes de classpath, mais aussi de déploiement: redémarrage en cas de crash, monitoring, exploitation des fichiers de logs, etc. Les technologies «abordables» donc, avec des cycles de développement
courts, permettent de garder un avantage compétitif non négligeable sur ce web en perpétuelle évolution.

Quelques articles intéressants (en anglais):

• http://www.process-one.net/en/blogs/article/web_20_shifting_from_get_fast_to_get_massive/


• http://public.yahoo.com/bfrance/radwin/talks/yahoo-phpcon2002.htm


• http://raibledesigns.com/rd/entry/php_vs_java_which_is


• http://www.epicserve.com/blog/69/python-and-django-ruby-on-rails-and-php

Et une spéciale dédicace à Sylvain Wallez, qui m'a aiguillé sur toutes ces pistes de réflexion intéressantes depuis 2004.