par Christophe Tronche.
Paru dans l'Interacteur No 3, Juin 1997.
En inventant l'interaction graphique, Ivan Sutherland, a créé un espoir: celui de piloter les ordinateurs d'une façon plus intuitive qu'en entrant des rébus par le moyen d'une télétype. Grâce à l'augmentation de la puissances des ordinateurs et au travail acharné des chercheurs, les ordinateurs graphiques-multimédia-beaucoup-de-mémoire-et-de-cpu, d'aujourd'hui, sont munis d'interfaces utilisateurs évoluées (?) programmées grâce à des boîtes à outils sophistiquées, implémentées dans des langages élaborés.
Et c'est sous ces cieux idylliques que résonne le tonnerre de l'approche des hordes barbares. Un nouveau langage et une "nouvelle façon de créer des interfaces", au dire de son promoteur, bouscule tout, envahit tout, s'insère partout. Il se pare des atours les plus courus du moment: "orienté-objet" (un peu défraichi, peut-être), "portable", "cross-plateforme", et même "programmation d'Internet". Il serait le "standard de l'industrie", ce qui coupe évidemment court à toute vélléité de contradiction.
Je veux bien sûr parler de Java.
Un langage banal doté d'une boîte à outils rabougrie à été lancé avec la stratégie du marchand de lessive par un constructeur encore riche, mais en perte de vitesse. Rien de critiquable là-dedans, il est normal qu'une compagnie commerciale fasse tous les efforts possibles pour imposer ses produits, verrouiller des standards ou fidéliser sa clientèle. Mais était-il indispensable que la communauté des enseignants-chercheurs lui prête main-forte ? Et que celui qui enseigne dans une université n'ayant pas inscrit Java dans un de ses cours de la prochaine rentrée me jette la première pierre...
J'ai souvent considéré l'exercice consistant à critiquer un langage de programmation comme inutile et stérile. Tant pis.
Java mérite certes par quelques avantages: un premier pas vers l'intégration du multithread; la possibilité de générer un byte-code portable structuré en classes, ce qui permet dans une certaine mesure le transport d'applications sur le réseau; et surtout la gestion automatique de la mémoire. Mais le plus extraordinaire est que Java adopte nombre de solutions déjà condamnées par l'histoire. Par exemple:
Java utilise l'héritage pour créer des composants réutilisables (comme Smalltalk). Or Java ne supporte que l'héritage simple, alors que l'héritage multiple à été introduit dans Smalltalk précisément pour permettre la réutilisation [1]. Notons également que la réutilisation par héritage est de nos jours battue en brèche et s'efface progressivement devant la réutilisation par composition externe, telle qu'elle est mise en oeuvre par exemple dans la STL [2]. La structure syntaxique qui supporte cette réutilisation, chère au coeur des praticiens du génie logiciel, est la généricité telle que l'implémente les templates en C++ (rappelons la généricité a été ajoutée dans C++ après la constatation que l'héritage, même multiple, seul était insuffisant [3]).
Si on change l'interface d'une superclasse, il faut recompiler toutes les sous-classes. Garder la trace de ces dépendances est à la charge de l'environnement de programmation (projet sous Metrowerks, makefile avec javac). En ceci, Java ne diffère pas de n'importe quel autre langage (par exemple C ou C++). Mais un langage qui proclame permettre l'écriture d'applications distribuées doit faire mieux. Détecter qu'une classe tente de télécharger une superclasse obsolète est le minimum requis [4]. Ce n'est pas le cas avec Java: les fichiers byte-code ne contiennent ni date ni numéro de version, et c'est le mécanisme de transport qui a la charge de ces contrôles. C'est à dire que le plus souvent, personne ne s'en occupe (Netscape Navigator par exemple, ne recharge pas les Applets devenues obsolètes).
La version 1.1 de la toolkit est déjà fortement incompatible avec la version 1.0. Il existe au moins trois interpréteurs susceptibles de faire tourner Java: Netscape / MSIE, HotJava et l'interpréteur Java du Software Development Kit. Tous sont incompatibles deux à deux, ce qui rend en pratique aléatoire l'exécution d'un programme d'une plateforme à une autre. D'autre part, il existe plusieurs versions de la AWT (Abstract Window Toolkit, la boîte à outils qui contient des lignes et des boutons), ce qui assure un deuxième niveau d'incompatibilité. Par exemple les primitives de tracé reçoivent la zone à rafraîchir dans un objet dérivant de la classe "shape" dans la AWT 1.1, mais utilise un jeu de primitives différent pour obtenir un rectangle dans la 1.0, dans laquelle les "Shapes" ne sont pas présents: incompatibilité entre Netscape Navigator et le JDK Java interpreteur, mais surtout l'illustration du fait que Sun a mis Java sur le marché (si on peut dire) dans la précipitation, pour occuper le terrain, ce qui nous promet quelques belles tranches d'incompatibilité dans un proche avenir.
Plusieurs fournisseurs ont inscrit à leur catalogue des outils qui permettent, par exemple, un certain degré de compatibilité entre Motif et / ou les MFCs et Java (citons X-Designer d'IST pour ne pas parler dans le vide). Pour ce faire, l'interpréteur doit pouvoir disposer de bibliothèques locales (et dépendant de la plateforme) qui émule le fonctionnement de Motif. Inutile de dire que ces bibliothèques ne sont pas transmissibles sur le réseau sous forme d'Applet, puisque leur rôle est précisément d'émuler des fonctionalités qui ne peuvent être écrites en Java avec la AWT.
Votre serviteur a enfilé une jolie veste et une cravate pour se fondre, inaperçu, dans la masse de quelques entreprises de la région histoire d'obtenir une mesure, si grossière soit-elle, du taux de pénétration de Java dans l'industrie locale. En dépit des affirmations péremptoires de la presse spécialisée (mais pas toujours très bien informée), il a été pratiquement impossible de trouver la trace de Java dans les développement en cours, ou même projetés. Quand parfois la question était posée, au détour d'un séminaire développeur, les réponses étaient toujours rassurantes:
- "Si nos clients nous demandent une API Java, nous la leur fournirons bien sûr, mais nous n'avons pas de développement particulier prévu autour de Java."
- "On ne veut pas gaspiller notre effort sur un produit instable. De toute façon, Java est trop lent."
- (petit sourire entendu) "Ah oui, Java. Espérons que nos concurrents vont être assez naifs pour dépenser des ressources là-dessus..."
En fait les seuls utilisateurs de Java dans l'industrie semblent être l'armée des thésards qui financent la fin de leur thèse en montant des sites Web...
Alors que l'une des tendances des dernières années a été de sortir les interfaces du stéréotype bouton - menu - scrollbar pour envisager de nouvelles et plus intuitives formes d'interaction, Java ne propose dans la AWT que la scrollbar, le menu et le bouton. La nouvelle API Java2d supposée prolonger la AWT ne contient aucune primitive d'interaction. Par ailleurs, si on peut saluer une boîte à outil graphique qui fournisse enfin directement l'anti-aliasing, Java2d n'est pour le moment qu'une API, et nous devrons attendre les implémentations pour pouvoir juger des performances d'un système qui ne brille pas jusqu'ici par sa rapidité.
Le drag-and-drop est un exemple de mécanisme d'interaction plus favorable à la manipulation directe. Il en est question dans la description de JavaBeans, qui est un vrai "white paper", puisque la section concernant le drag-and-drop y apparait en blanc [5].
D'ailleurs, comme nous le rappelle fort à-propos Joëlle Coutaz le problème d'une interface portable va plus loin que de simples boutons multi-plateforme [6].
Sun prétend avoir dépensé 100 millions de dollars en marketing sur Java en deux ans, plus de 250 fois le budget de fonctionnement annuel d'un laboratoire de recherche public comme on en trouve en France (hors salaires), et il n'y a sans doute pas 200 laboratoires de recherche en informatique dans notre pays. C'est dire que d'un certain point de vue, Sun a dépensé pour imposer Java un budget supérieur à l'effort de recherche public français en informatique. Java fera donc sa place au soleil, car il est impossible de lutter contre une telle machine de guerre. Et ce n'est pas notre rôle.
Il est, me semble-t'il, du rôle des scientifiques et des enseignants de promouvoir des solutions élégantes qui tirent vers le futur, des solutions dont un chercheur puisse se sentir fier, bâties sur au moins deux décennies de réflexions visant rapprocher l'ordinateur de la machine, non des solutions éculées et sans surprise soutenues par un marketing agressif. Cette réflexion, nous ne pouvons la mener que loin du tapage des batailles que se livrent les constructeurs, c'est pourquoi il est temps de clore cet article pas trop sérieux.
[1] Alan H. Borning et Daniel H. Ingalls. Multiple Inheritance in Smalltalk 80. Proc. of AAAI 92, p 234-237.
[2] Alexander Stepanov et Meng Lee, The Standard Template Library. ANSI X3J16-94-0095/ISO WG21-NO482.
[3] R.G.G. Cattell, editeur. The Object Database Standard: ODMG-93, Release 1.1. Morgan Kaufmann Publishers, 1994.
[4] Frank Manola, editeur. X3H7 Object Model Features Matrix. Object Database Management Group.
[5] http://splash.javasoft.com/beans/glasgow.html#draganddrop
[6] Joëlle Coutaz. PAC-ing the Architecture of Your User Interface. Proc. of DSVIS'97 (a paraître).