JDNet Solutions inaugure une nouvelle série d'articles consacrés aux idées reçues de l'informatique. Avec un double objectif: examiner dans quelle mesure les promesses des technologies ont été tenues et permettre au plus grand nombre de prendre le train en marche.

"Write once, run anywhere" (codez une fois, exécutez n'importe où) : le slogan est connu et il accompagne le langage Java depuis son lancement par Sun. Et, de fait, lorsqu'apparaît Java sur la scène des technologies Web (en 1995, quelques années après son invention), sa portabilité, autrement dit la possibilité d'exécuter sans réécriture des développements Java sur un large éventail de plates-formes, représente son principal argument de séduction. Rappelons que pour assurer cette portabilité, Java passe par l'entremise d'une machine virtuelle: un environnement d'exécution, disponible sur l'essentiel des plates-formes du marché, et qui prend donc en charge le traitement du code Java.

Cette "universalité" de Java fait mouche: elle permet d'enrichir les pages Web alors très statiques d'appliquettes (de petits programmes) capables de s'exécuter sur les principales machines du marché. Avec HTML, le Web avait déjà un langage de description de pages universel ; avec Java, il gagne un langage de programmation. Un petit miracle en somme. Qui aujourd'hui mérite cependant d'être nuancée. Pour deux raisons: primo parce que cette portabilité de Java est devenue plus discutable; secundo parce que l'intérêt de Java est désormais tout autre.

Java déserte le poste client
Une raison majeure explique ce glissement: si à l'origine on a beaucoup attendu de Java sur le poste des utilisateurs connectés au réseau, au final son champ d'action véritable s'est avéré être avant tout du côté des serveurs. La faute entre autres aux contraintes des postes clients qui, situés derrière un firewall ou bien encore disposant d'une connexion à faible débit au Net, gèrent plus ou moins bien le téléchargement et l'exécution d'appliquettes Java. Ces contraintes ont conduit les développeurs à privilégier des applications Web qui se "contentent" de retourner à l'utilisateur (qu'il soit au bureau ou à la maison) de strictes pages Web.

Mais Java n'a pas pour autant été abandonné. Bien au contraire. En quête d'un langage de programmation côté serveur (pour les traitements donc qui s'exécutent sur les machines serveur et non sur le poste de l'utilisateur), les développeurs ont adopté Java en masse. Pas seulement pour la portabilité du langage mais aussi pour sa syntaxe (proche d'un autre langage, le C++) et pour son ancrage dans l'univers des applications Web. Un engouement qui s'amplifie au fur et à mesure que Sun dessine autour de Java le "modèle J2EE" (Java 2 Enterprise Edition): un ensemble de services qui, capitalisant sur Java, standardisent par exemple comment accéder à une base de données (via l'interface Java Database Connector, JDNC) ou encore comment générer des composants Java interopérables (ce qu'on appelle des Enterprise Java Beans, EJB). Un environnement mis en oeuvre à travers les serveurs d'applications conformes au modèle J2EE (comme Weblogic Server de Bea ou Websphere d'IBM).

Du langage à l'architecture
On le comprend, en quelques années, les applications Java ont radicalement changé de nature: à l'origine conçues par exemple pour améliorer l'interactivité des pages web et être exécutées sur le poste de l'internaute, les développements Java concernent aujourd'hui des traitements plus complexes mis en oeuvre sur des serveurs. Pour être plus précis d'ailleurs sans doute faudrait-il parler des développements "Java/J2EE". Et la portabilité dans tout ça ?

Sun n'a pas fait une croix dessus. Loin de là puisque le modèle J2EE est aussi élaboré avec ce souci de portabilité: un développement Java/J2EE devrait ainsi pouvoir s'exécuter sur toute plate-forme qui se conforme au modèle. Dans les faits, cette portabilité semble encore très partielle. Logique: un développement Java/J2EE est plus complexe qu'une appliquette expédiée à un navigateur Web et le modèle J2EE connaît des différences d'interprétation d'un éditeur de logiciels à un autre qui nuisent à cette portabilité. Cela n'empêche manifestement pas le modèle Java/J2EE de prospérer. Pour une raison évidente: l'intérêt du modèle réside moins désormais dans la portabilité des développements que dans la standardisation du modèle même. Une standardisation qui permet aux entreprises d'uniformiser, donc de rationaliser, leurs architectures informatiques. Ainsi que les compétences associées. Voilà pourquoi aujourd'hui la qualité première de Java réside moins dans son caractère multi-plate-forme que dans la standardisation du modèle qui l'accompagne.