Malgré leur succès sur le terrain, la question de la pertinence des technologies Java dans le paysage du Web moderne est une problématique qui revient relativement fréquemment, surtout dans la bouche des professionnels de la maîtrise d’ouvrage qui s’avouent eux-mêmes parfois un peu dépassés par les avantages et inconvénients techniques de chaque alternative. Leur interrogation est tout-à-fait légitime : beaucoup savent que le langage Java a été créé il y a une quinzaine d’années (préhistoire, que dis-je, big bang du Web !), et qu’il a été adapté plus tard pour le Web, et non créé pour lui.
« D’accord », nous dit-on, « Java a très bien survécu jusqu’ici ; mais survivra-t-il aux prochaines ères glaciaires, éruptions volcaniques géantes, chutes de météorites, auxquelles le Web nous a habitué depuis sa formation ? Et auquel cas, sa fragilité potentielle face à ces phénomènes n’en fait-elle pas une solution non-pérenne ? »
Le problème est sensiblement plus compliqué que ça, aussi je vous propose d’embarquer pour un tour d’horizon qui se veut objectif, synthétique et honteusement vulgarisé des technologies Web Java face à ses concurrents en 2010, et de vous présenter ma vision plus subjective de professionnel du Java Web quant à ses perspectives d’évolutions logiques, aussi dramatiques puissent-elle s’avérer !
D’où viens-je, qui suis-je, mais surtout dans quel état j’ère ?
Déjà, comme il est communément su, Java est le fruit d’un rendez-vous manqué entre Sun Microsystems et la domotique, censée révolutionner notre chaumières à l’aurée du rêve de l’an 2000. Le langage était pensé pour savoir manipuler des « objets » (qui étaient, réellement, des « objets » physiques : volet, four micro-ondes, etc.) et leur appliquer des actions, que l’on appelait « méthodes ». L’intérêt populaire pour la domotique attendu par Sun jouant les arlésiennes, la domotique est enterrée ; Java est offert aux développeurs de clients lourds, qui commencent à trouver des attraits intéressants à sa manière d’implémenter l’orientation objet. La domination de Java comme langage de référence pour l’orienté objet est en chemin…
Alors que le Web statique (ou très peu dynamique) s’étend exponentiellement, le besoin se fait de plus en plus pressant d’outils qui soient capables de générer le code HTML à la volée, au lieu des traditionnels fichiers HTML agrémentés de quelques scripts CGI limités. La mode étant à l’objet Java, quelqu’un y voit une manière simple de représenter la requête HTTP, la session HTTP, etc., comme des objets programmatiques, et Sun crée un ensemble de bonnes pratiques et d’outils (on appelle ça « framework ») pour appliquer les concepts Java au Web, framework qui sera plus tard renommé en le « JEE » qu’on connaît aujourd’hui.
A la même époque, d’autres visionnaires attaquent le problème par l’autre côté : au lieu de produire tout un ensemble d’outils généralistes et pré-installés dans un framework pour attaquer un langage très métier, pourquoi ne pas plutôt insérer du script dans le HTML pour le transformer partiellement en code exécuté du côté du serveur ? Parmi ces visionnaires, le langage PHP fera surface, et prendra la place qu’on lui connaît aujourd’hui.
Cela dit, la transformation de la chenille PHP en papillon PHP ne s’est pas faite en un jour, et il aura fallu quelques versions majeures avant que PHP n’implémente finalement une orientation objet pour sa partie métier (les premiers éléments apparaissent dans PHP4 en mai 2000, et l’implémentation ne sera pas complète avant PHP5.3 en juin 2009). Faisant face aux détracteurs de son orientation très « couche vue » (le « V » dans « modèle MVC »), des outils permettant de structurer le code (rappelez-vous : « frameworks ») font leur apparition, et transforment le PHP en langage mature, capable de gérer tout type de complexité d’application Web.
Dans le même temps, les détracteurs de la lourdeur du framework Web Java permettent également à Sun de développer ses technologies orientées script (JSP/taglibs), rapprochant d’année en année les deux technologies l’une de l’autre, et les rendant progressivement capables de répondre aux mêmes besoins.
Vroum ?
Une fois n’est pas coutume, je me permets une analogie un peu tirée par les cheveux : admettons que vous n’ayez pas pour but de construire un site Web avec tous les services dont vous avez besoin, mais de construire une voiture avec toutes les options qui vous font envie, lesquelles évoluent au cours du temps. Imaginons que vous n’avez pas besoin de mettre votre site en ligne, et de lui trouver des utilisateurs ; mais que vous avez besoin de faire rouler votre voiture avec options. Vous y êtes ? Bien.
Dans ce cas, vous pouvez considérer Java comme un socle automobile très solide, mais très, très, (trop ?) complet, une architecture nativement compatible avec tout type d’essuie-glace, auto-radio, ou climatiseur, moyennant quelque câblages particulièrement complexes. Pour vulgariser catastrophiquement, lorsque vous achetez la voiture, vous achetez aussi tous les outils qui vous permettront de connecter le klaxon de vos rêves, quel que soit le klaxon de vos rêves !
Par opposition, PHP a été créé comme une voiture à pédales. (Je vois déjà certains de mes collègues PHPistes se lever au fond de la salle !) A l’origine, sa couverture technique était très limitée, mais le langage a évolué avec le web, pour devenir, option par option, ajout par ajout, une berline particulièrement performante. Et cette performance a une raison : tous ces ajouts sur PHP se sont opérés en gardant à l’esprit la simplicité et la légèreté du moteur initial. Du coup, au lieu d’embarquer nativement tous les outils qui vous rendent compatibles avec tout, vous devrez les ajouter vous-mêmes au fur et à mesure, ne gardant constamment que le strict minimum.
On se retrouve donc avec des garagistes PHP reprochant à Java la lourdeur de son système sur-câblé ; affirmation à laquelle les garagistes Java répondent en dénonçant le manque de pré-conditionnement (et parfois de support technique) de PHP, rendant les interventions et les contrôles techniques trop peu normalisés et brouillons, et du même coup parfois complexes ; ce à quoi les PHPistes répondent que le recâblage des options Java peut aussi être très complexe, etc.
Et sinon, on n’oublie pas quelqu’un là ?
C’est maintenant mes collègues pro-Microsoft que je vois trépigner, de peur d’être négligés ! Il faut bien comprendre que lorsque Microsoft s’est lancé dans la course des technologies Web serveurs avec son framework .Net, il en existait déjà une multitude, dont l’écrasante majorité s’appuyait soit sur du Java, soit sur du PHP. La voiture Java « surcâblée » et la voiture PHP « trop peu câblée » étaient à l’époque les deux principales alternatives (qui ont évolué, certes, j’y reviendrai).
La proposition de Microsoft était donc simple : supprimer tous ces câblages censés garantir la compatibilité avec un maximum de types d’options ! L’idée était que vous achetiez une voiture de sport haut-de-gamme, mais compatible avec une liste très limitée d’options toutes fournies avec, Microsoft promettant que ces options couvriraient de toute façon tous vos besoins (vous n’aurez pas le klaxon de vos rêves, mais un klaxon .Net, qui marche très bien). Et de plus, la voiture de sport est livrée avec plus de couverture initiale qu’aucune autre technologie n’a jamais fournie.
Quelques exemples concrets :
– Pour développer en Java, vous pouvez utiliser n’importe quel IDE, dont les plus célèbres sont Eclipse et NetBeans ; pour développer en PHP, vous avez une offre encore plus large, avec parmi les plus communs : Netbeans, Zend Studio, Eclipse PHP, PHPEdit, etc. ; mais pour développer du .Net, vous n’aurez jamais qu’une possibilité, Microsoft Visual Studio.
– Vous pourrez exécuter votre Java en production avec JBoss, Tomcat, Glassfish, WebSphere, WebLogic, … ; pour votre PHP, la majorité écrasante revient à la librairie PHP en tant que module Apache, mais on trouve aussi des modules pour Zend Server, LightHTTPd, et même aussi Microsoft IIS, ou encore des implémentations alternatives comme HipHop for PHP, fourni par Facebook ! Pour faire tourner votre .Net, vous n’aurez jamais que Microsoft IIS.
– Nos clients sont habitués à voir nos développeurs Java ou PHP débarquer chez eux avec leur portable sous Linux Ubuntu, Microsoft Windows, ou Mac OS X ; pour du .Net, ils ne pourront être que sous Microsoft Windows.
– …
Le pari de Microsoft de limiter la compatibilité à quelques outils très contrôlés lui permettait d’offrir une garantie intégrale (et coûteuse) sur toute la chaîne de réalisation, de l’OS du développeur à l’environnement de production, et de faciliter critiquement le câblage qui posait tant problème à ses confrères.
« Avec le temps, va… »
Les révolutions continuelles auxquelles le Web nous a maintenant habitués entre 1995 et 2010 auraient pu dramatiquement étouffer l’un de ces modèles ; seulement aujourd’hui, le temps ayant fait son office, il s’avère que les trois technologies sont toujours fortement présentes, et ne donnent pas de signes d’agonie du tout, bien au contraire ! PHP a clairement assis sa position de leader, mais les trois technologies ont eu l’occasion d’évoluer et de gagner en maturité.
Le modèle de .Net (qui est, pour rappel, légèrement plus récent) n’a pas évolué de façon sensible, et reste basé sur un socle applicatif solide et sur le contrôle et la garantie d’un maximum d’outils ; sa couverture technique s’est très largement étendue au gré des critiques des détracteurs et des demandes des développeurs, et sa couverture d’outils compatibles a également évolué, pour le mettre en concurrence avec ses confrères.
Pour les puristes du modèle MVC bien construit (dont le PHP de base ne facilite pas l’implémentation, à la grande critique de ses détracteurs), de nombreux frameworks PHP ont trouvé leur place sur le marché, qui organisent et normalisent les développements, et fournissent quelques pré-câblages à l’image de JEE. Chez Clever Age, nous avions fortement poussé le framework Symfony dès ses premiers pas, car sa robustesse et sa simplicité nous avaient déjà convaincus ; et aujourd’hui, nous nous félicitons de le voir devenir le framework particulièrement populaire que l’on connaît.
On peut donc aujourd’hui considérer que la démocratisation de Symfony et des autres frameworks PHP a révolutionné l’utilisation du langage PHP en entreprise aujourd’hui.
—-
– Et Java ?
– Qu’a-t-il fait pour amenuiser ses faiblesses par rapport à ses concurrents, et réagir à ses détracteurs ?
– Quelles révolutions lui sont arrivées qui l’ont modernisé ?
—-
C’est bien le problème, et le fondement des interrogations qui nous viennent de la maîtrise d’ouvrage : il n’y a pas vraiment eu de révolution Java/JEE-esque ! Toutefois, une force de Java sur ses confrères vient justement de la base solide, polyvalente et minimale qu’est le framework JEE, sur lequel des briques très variées et au câblage facilité viennent s’ajouter. Et ces briques-là par contre, ont critiquement évolué, année après année. La maturité arrive donc à Java par la maturité de ses extensions, le modèle JEE ayant lui-même peu évolué, ou bien souvent par des extensions peu transcendantes, et apportant plus de lourdeur que d’innovation.
Et est-ce que ça suffira ?
C’est toute la question, à laquelle toute réponse ne peut être qu’évasive ; mais devant la facilité grandissante pour réaliser des applications métier complexes avec des frameworks PHP modernes ou des .Net prêts à servir « out-of-the-box », il convient à tout expert technique Java, et par extension à sa maîtrise d’ouvrage, de s’intéresser aux alternatives qui tentent de séparer Java/JEE de ses contraintes historiques, et de le placer dans un contexte plus proche des deux autres modèles du marché.
Et ces alternatives existent aujourd’hui, et commencent même déjà à gagner en maturité :
– { {du Java à la sauce .Net }} : on trouve aujourd’hui des frameworks pré-intégrant une sélection des sous-frameworks Java afin d’avoir un outil fonctionnellement complet « out-of-the-box », et à la compatibilité limitée pour améliorer fortement la facilité de câblage et assurer une couverture technique optimale. Théoriquement, tout comme .Net, sans les coûts Microsoft (en pratique, et comme toujours, il s’avère que l’absence d’éditeur a des avantages comme des inconvénients) L’initiative Grails, qui n’est pas particulièrement récente, abonde en ce sens (je vous conseille d’ailleurs cet excellent article sur Grails de notre excellent Matthieu Guillermin, de même que ce tout aussi excellent article beaucoup plus récent sur Groovy, par notre tout aussi excellent Stéphane Prohaszka !)
– { {du Java à la sauce PHP }} : le but est donc de transcender les règles établies lors de l’adaptation de Java au Web dans les années 90, menant à la création de l’ancêtre de JEE, et de repartir du langage pour l’adapter plus simplement, dans un contexte de site simple sans besoin de framework lourd. C’est particulièrement ambitieux, car les serveurs d’application Java actuels sont massivement compatibles JEE, et il faut donc également réaliser son propre serveur d’application. L’initiative Play! Framework, qui acquiert une maturité progressive et que nous suivons très particulièrement, permet d’outrepasser JEE pour utiliser le langage Java « à la » PHP ; c’est-à-dire sur la base de scripts et d’architecture simple (vous pouvez trouver un peu plus d’information sur notre fiche produit sur Play!, et encore plus sur le site du projet).
Qu’est-ce qu’il faut conclure de tout ça ?
Déjà, Il faut nuancer et retenir que la pertinence actuelle et à venir de Java n’est pas liée uniquement aux aspects techniques de Java lui-même, mais aussi à d’autres facteurs que je n’ai pas du tout évoqués : notamment, le fait qu’aujourd’hui, la couverture fonctionnelle de l’outil final (CMS, GED, etc.) est de plus en plus déterminante dans le choix de la solution technique, sans doute plus que la facilité des développements spécifiques (en Java, .Net, PHP, pour le coup) ; également, le fait que le rachat de Sun par Oracle a donné place à quelques décisions récentes de la part d’Oracle ne rassurant pas quant à leur opinion sur l’ouverture salutaire de Java (départs provoqués de nombreux employés charismatiques dans la communauté open-source, attaque en justice de Google pour leur utilisation de Java dans Android, etc.)
Puisqu’on n’en est pas à une atténuation près, on peut aussi se permettre de nuancer toute conclusion à long terme, en rappelant que les aspects techniques des technologies Web sont un paysage en évolution constante et souvent spectaculairement rapide (j’en veux pour preuve un article de ce même blog publié par Denis Delangle sur le même sujet il y a près de deux ans et demi, où l’on s’aperçoit que les initiatives prometteuses de l’époque ont beaucoup changé aujourd’hui !)
Toutefois, si l’on met de côté ces éléments, et que l’on garde en visée uniquement les caractéristiques techniques de Java/JEE à moyen terme, il se pourrait que, à la manière de PHP il y a quelques années, nous soyons à la veille d’une révolution intégrale sur la manière d’utiliser Java pour le Web. Je ne dis pas que cette révolution soit nécessaire (les architectures Java modernes, basées sur les frameworks en évolution constante, restent particulièrement robustes et évolutives en l’état), et je ne dis surtout pas qu’il faille la provoquer. D’ailleurs je ne dis même pas que Java soit nécessaire non plus. Toutefois, en tant qu’experts Web, techniques ou fonctionnels, je pense sérieusement qu’il nous faut clairement suivre l’évolution de ces technologies prometteuses au millimètre, et nous tenir prêts autant que possible en attendant le prochain virage…
—-
Et vous, qu’en pensez-vous ? Croyez-vous que les architectures Web Java/JEE standards peuvent devenir obsolètes ? Pensez-vous que les initiatives modernes ont pour objectif de combler ce dépassement ? Pensez-vous qu’une révolution de l’utilisation de Java/JEE soit suffisamment crédible pour valoir l’effort de se tenir prêt dès aujourd’hui ?
