Le concept Java

Le concept Java
CHAPITRE 1
Java
9
eivd
1.1
Télécommunications
mjn
Idée de base
Java est une technologie qui prend sa source dans le World Wide Web, et qui est née
dans les bureaux de développement de Sun Microsystems. L’idée de Java est de mettre à disposition des usagers d’un réseau non plus simplement des informations sous forme de pages
HTML, comme le fait le Web, mais d’offrir à tout un chacun des applications téléchargeables.
Dans un milieu hétérogène, ce but est difficile à atteindre en raison de la multiplicité
des systèmes d’exploitation, CPU, etc... rencontrés sur le réseau. L’idée poursuivie par Sun
Microsystems est de combiner un navigateur Internet avec une machine virtuelle. Cette idée
est suffisamment mûre pour que tous les principaux éditeurs de logiciels aient immédiatement pris le train en marche1.
1.1.1
Principe de Java
Java est un langage de programmation destiné à une utilisation sur une machine virtuelle (donc, sans existence physique). Sa syntaxe se fonde très fortement sur C++, dont il est
par ailleurs un sous-ensemble par certains aspects, alors que d›autres caractéristiques du langage sont réellement originales. Un navigateur Internet supportant Java peut télécharger un
programme Java situé sur un serveur HTTP et l’exécuter localement.
FIGURE 1.1
Principe de Java en conjonction avec HTTP
Serveur HTTP
Viewer HTTP
(p. ex. Netscape)
Applications
téléchargées
Machine
virtuelle
JAVA
NETWORK
Un navigateur capable d’interpréter du code Java détecte automatiquement la présence
d’un hyperlien Java, et active la machine virtuelle Java (MVJ) locale. Le code Java se pré1. Actuellement, ces éditeurs sont essentiellement (hormis Sun Microsystems) Netscape Communications, IBM, HP et
quelques autres. Même Microsoft, bien qu’avec nombre de réticneces, se voit forcé d’adhérer, du bout des lèvres, à Java.
10
Java
eivd
Télécommunications
mjn
sente sous la forme de pseudo-code (bytecode), similaire à certains métacodes utilisés dans
les années 80 pour des langages de programmation pour micro-ordinateurs (UCSD Pascal pcode, par exemple). L’intérêt de ce principe est que l’application peut s’exécuter indépendemment de la machine client, et que le serveur est de ce fait assuré de pouvoir mettre à disposition une application sans avoir à connaître le client qui va l’exécuter, par opposition aux
systèmes conventionnels, où il est nécessaire de mettre à disposition plusieurs versions d’un
applicatif.
Ces applications téléchargeables se nomment des applets, en langage Internet. Les
applets sont de “petites applications1”, idéalement monolithiques, qui s’exécutent dans le
cadre d’une page Web. Une applet est exécuté à partir d’un hyperlien HTML, dont la syntaxe
est la suivante :
<applet standard-attributes>
applet-parameters
alternate-contents
</applet>
Nous reviendrons sur cette syntaxe plus loin dans cet ouvrage.
La signification de l’acronyme Java reste assez mystérieuse. L’explication selon
laquelle Java signifierait simplement “Just Another Vague Acronym” semble la plus probable... Quelques étudiants de l’EIVD, chargés dans le cadre d’un travail personnel d’étudier le
langage, ont proposé “J’Ai Vite Appris”; que chacun critique cette interprétation à la fin de
ce cours.
A l’origine destiné principalement aux applications client, donc à la fabrication
d’applets, Java a peu à peu grignoté une part significative du marché des applications à part
entière. L’élégance du langage associée à sa portabilité sur diverses plate-formes et divers
systèmes de fenêtrage (Mac, Windows, X11) encouragent les éditeurs ne disposant pas d’un
système d’exploitation propriétaire à porter leurs applications phares sur Java, et surtout à
développer de nouvelles applications entièrement en Java. Par ailleurs, diverses extensions
du langage (servlets, Java Server Pages, etc...)ainsi que l’orientation clairement réseau de
l’environnement de développement font de Java une alternative intéressante aussi au niveau
des applications serveur.
On peut donc dire que Java, du langage de niche qu’il était à son origine, uniquement
justifié dans un environnement Internet, s’est aujourd’hui avéré un langage tout à fait universel.
1.1.2
Motivations à la base de Java
Il est toujours intéressant de faire un rapide retour en arrière, lorsque l’on étudie une
technologie ou un procédé, de manière à mieux comprendre les motivations ayant conduit à
faire certains choix plutôt que d’autres. Il en va ainsi de Java, qui à l’origine n’était pas prévu
1. Dans les milieux francophones, le terme a reçu plusieurs traductions, dont appelettes ou appliquettes. L’unanimité ne
semblant pas près d’être réalisée, nous conserverons ici le terme anglo-saxon, en le considérant comme féminin (à l’instar du mot “application”). N’en déplaise aux puristes...
Java
11
eivd
Télécommunications
mjn
pour être utilisé dans le cadre où on l’utilise actuellement. En fait, l’équipe ayant developpé
Java (anciennement appelé Oak, jusqu’à ce qu’on s’aperçoive que ce nom était protégé),
avait reçu pour mission de développer un langage destiné au développement de logiciels pour
des appareils électroniques portables. Le cahier des charges du langage reflétait ce but : le
langage devait être
• simple
• s’appuyer sur une base connue
• utiliser peu de place mémoire
• produire du code d’une stabilité à toute épreuve
Les deux premières clauses servaient à minimiser les coûts de développement. Un langage simple, et semblable à un langage déjà connu devait assurer la disponibilité rapide de
programmeurs performants pour ce langage. D’autre part, un système portable doit consommer peu et être petit, ce qui limite la quantité de mémoire utilisable. Enfin, ce type d’appareil
est utilisé dans des circonstances très variables, et il vaut mieux que le code produit ne soit
pas (ou aussi peu que possible) sujet à des erreurs de gestion de mémoire, mémoire par
ailleurs limitée pour les raisons précédemment citées.
Le projet Java, conduit chez Sun Microsystems, ne put finalement jamais aboutir au
résultat escompté. Le groupe de développement responsable de Java fut progressivement dissous, et le projet allait être abandonné lorsque l’un des membres rescapés du groupe eut
l’IDEE. Java pouvait être un outil pour la programmation interactive sur le Web. La légende
veut que l’auteur de cette idée développa en un week-end un navigateur compatible Java, et
le présenta à Sun, qui investit dans l’idée. En quelques mois fut developpé le premier “browser” pour Java, appelé HotJava. Ce navigateur fut présenté officiellement le 23 mai 1995;
cette date est à considérer comme une date marquante dans l’histoire d’Internet et du World
Wide Web. Même avec le peu de recul dont nous disposons actuellement, cette date peut
d’ores et déjà être considérée comme significative pour l’informatique et les télécommunications en général.
Sun Microsystems eut le mérite de proposer d’emblée un environnement de développement gratuit, se fondant sur les expériences positives que AT&T avait faites à l’origine avec
UNIX. Le succès de Java fut, et reste rien moins que foudroyant; malgré quelques défauts
(lenteur, gourmandise en ressources, compatibilité entre versions successives...) la qualité du
concept Java continue à faire chaque jours de nouveaux adeptes; le marché émergeant de la
mobilité (GPRS, UMTS) fournit au concept Java de nouvelles opportunités de montrer ses
qualités; dans cette même optique, les aspects "sécurité" implantés dans le langage Java sont
très intéressantes pour le téléchargement de code, surtout quand on ignore (comme c’est fréquemment le cas lorsque l’on navigue sur Internet) la provenance du code que l’on est en
train d’exécuter...
12
Java
eivd
1.2
Télécommunications
mjn
La réalisation de java
Le challenge constitué par la création d’un langage utilisable sur le Web est formidable! Le Web est composé de centaines de milliers de machines, formant une galaxie de
noeuds de réseau disparates évoluant eux-même dans un environnement de périphériques
hétérogènes et totalement incompatibles. Vouloir unifier cette galaxie à l’aide d’un langage
de programmation tient de la gageure, voire de l’illusoire. De fait, Java ne parvient que partiellement à ce but; ce qui n’enlève en réalité rien à l’exploit. Java permet d’exécuter des
applications sur la très grande majorité des systèmes raccordés à Internet.
1.2.1
La notion de machine virtuelle
L’idée à la base de la réalisation de Java consiste à réaliser une machine virtuelle. Une
machine virtuelle est une notion bien connue des concepteurs de microprocesseurs, qui émulent la puce à construire à l’aide d’une simulation logicielle. Ceci leur permet de détecter
d’éventuelles erreurs de conception très tôt, avant même la première génération de masques
permettant la fabrication de la puce finale.
Il est possible d’implanter, de manière logicielle, une simulation d’une machine quelconque sur une autre machine, même si elle est très différente architecturalement de la
machine à émuler. Cette démarche n’est pas originale : de nombreux éditeurs de logiciels
l’ont empruntée, le plus célèbre ayant écrit un émulateur Intel 803861 sur des machines Macintosh (processeur Motorola 68000), SOLARIS (processeur SPARC), HP-UX (processeur
HP_PA) et nombre d’autres. Sun Microsystems a suivi la même démarche, mais pour inventer un processeur virtuel, la Java Virtual Machine (JVM).
Notons au passage que le code de l’application devant s’exécuter sur une machine virtuelle doit être compilé pour la machine virtuelle : il ne s’agit donc pas de code interprété,
car la machine virtuelle exécute un code qui pour elle, est “natif”. En revanche, la machine
elle-même est en quelque sorte interprétée; pour cette raison, et pour simplifier la terminologie, nous parlerons de “code interprété” pour du code s’exécutant sur une machine virtuelle.
Une machine virtuelle a de nombreux avantages. Il est (semble-t-il) facile de la rendre
sûre par rapport au système d’exploitation qui l’abrite, car on peut se permettre de lui imposer les limitations adéquates. On peut ainsi interdire à cette machine virtuelle d’utiliser
l’espace d’adressage de la machine réelle en contrôlant les mécanismes d’adressage des
objets en mémoire. Pour rendre le système encore plus sûr, on peut interdire à cette machine
toute utilisation de ressources externes autres que celles implantées de manière native dans la
machine virtuelle.
La machine virtuelle Java remplit tous ces critères, et nombre d’autres encore. Mais il y
a forcément un prix à payer (la gratuité devient de plus en plus chère, de nos jours...), et c’est
dans les performances des applications s’exécutant sur cette machine qu’il faut rechercher ce
1. Le produit en question est mieux connu sous le nom de SoftWindows.
Java
13
eivd
Télécommunications
mjn
prix. Une machine virtuelle est simulée par une machine réelle, et ne peut donc en aucun cas
parvenir aux mêmes performances qu’une application dite “native”. Le processus de simulation de la machine prend en effet du temps, d’autant plus de temps que l’on introduit de sécurités d’accès de la machine virtuelle aux ressources (mémoire essentiellement) de la machine
réelle. La pénalisation est d’autant plus sévère que la machine virtuelle ne dispose - par construction - que de registres virtuels, émulés par des positions dans la mémoire physique de
l’ordinateur hôte. Il est de ce fait parfaitement vain de vouloir optimiser un programme
devant s’exécuter sur une machine virtuelle : l’optimisation consiste surtout à éviter les accès
mémoire sur un système moderne, et ceci est pratiquement impossible sur une machine virtuelle, car le CPU est en mémoire!
Il existe pourtant quelques espoirs d’amélioration de la situation. On parle couramment, actuellement, de compilateurs natifs, de compilateurs de bytecode, ou encore de compilateurs JIT (Just In Time compiler). Ces diverses technologies permettent toutes de gagner
un facteur important de vitesse (parfois même de rivaliser avec du code natif), mais sont
encore, à l’heure actuelle (1999) souvent immatures. De plus, les machines virtuelles interprétant le bytecode ont fait d’énormes progrès, et les programmes Java deviennent tout à fait
utilisables sans toutefois encore rivaliser avec un homologue C++.
1.2.2
Les compilateurs natifs
Une des solutions consiste à utiliser un compilateur natif, traduisant directement le langage Java en un programme exécutable par le processeur de la machine. Le programme ainsi
produit n'est plus portable dans un environnement différent. Cependant, le programme source
reste portable en théorie, du moment qu'il existe également un compilateur natif dans les
autres environnements.
Cette solution présente toutefois deux inconvénients. Le premier a trait à la distribution
de l’application : le code produit par le compilateur n'étant plus portable, il faut en distribuer
autant de versions différentes de l'application qu'il y a de systèmes cibles.
En clair, si l'application doit tourner sur PC et sur Macintosh, il faudra que le support
employé pour la distribution (par exemple un CD-ROM) contienne les deux versions. Le
deuxième inconvénient n'est pas inhérent à l'utilisation d'un compilateur natif, mais il est
beaucoup plus grave. En effet, il peut arriver que le concepteur du compilateur soit tenté de
se simplifier la tâche en demandant à l'utilisateur d'apporter quelques légères modifications à
son programme.
Dans ce cas, c'est tout simplement la portabilité des sources qui est remise en cause.
Donc, avant de se décider à choisir un compilateur natif, il faut impérativement vérifier s'il
est compatible avec un programme "Pure Java" sans aucune modification. Cette certification
n’est à l’heure actuelle possible que par le biais des spécifications de Sun Microsystems.
1.2.3
Les compilateurs de bytecode
Une autre approche, pour améliorer la vitesse d'exécution des programmes Java, consiste à compiler le bytecode dans le langage du processeur de la machine cible. De cette
14
Java
eivd
Télécommunications
mjn
façon, la portabilité est préservée jusqu'au niveau du bytecode, ce qui peut être suffisant dans
bien des cas. Il reste alors à assurer la diffusion du code compilé en autant de versions qu'il y
a de systèmes cibles. Cette approche est satisfaisante pour la diffusion d'applications vers des
systèmes cibles connus. Une alternative est d’intégrer le compilateur de bytecode au programme d’installation du logiciel : on ne distribue alors que les différentes versions du compilateur.
En particulier, la diffusion sur support physique (CD-ROM, par exemple) se prête bien
à ce type de traitement. En effet, choisir un support physique implique généralement de connaître le système cible, car il faut s'être assuré que celui-ci est bien capable de lire le support
physique.
Ainsi, la diffusion d'une application pour PC et Macintosh implique d'utiliser un format
de CD-ROM hybride pouvant être lu dans ces deux environnements. Si un compilateur de
bytecode existe pour chacun d'eux, cela peut constituer une solution satisfaisante. Il peut
s'agir d'un compilateur, fonctionnant dans l'un des environnements, ou même dans un environnement totalement différent, et produisant du code natif pour l'environnement cible; on
parle alors de cross-compilation.
1.2.4
Les compilateurs JIT (Just In Time)
La solution précédente présente un inconvénient majeur si l'ensemble des environnements cibles n'est pas connu. Par exemple, si l’on crée une application devant être diffusée
sur Internet, on souhaitera que celle-ci fonctionne sur tous les environnements compatibles
Java, présents et à venir. Dans ce cas, la compilation du bytecode à la source (par le programmeur) n'est pas une solution envisageable. Les compilateurs JIT (Just In Time) sont supposés
résoudre ce problème.
Un compilateur JIT fonctionne sur la machine de l'utilisateur. Il compile le bytecode "à
la volée", d'où l'appellation Just In Time - Juste à Temps. Généralement, l'utilisateur peut
choisir d'activer ou non le compilateur JIT. Lorsque celui-ci est inactif, le programme est
exécuté par la machine virtuelle. Dans le cas contraire, le programme en bytecode est compilé dans le langage du processeur de la machine hôte, puis exécuté directement par celui-ci.
Le gain de temps d'exécution est évidemment compensé en partie par le temps de compilation. Pour un programme s'exécutant de façon totalement indépendante de l'utilisateur, ou un
programme ne s’ exécutant qu’une seule fois, le gain peut être nul.
En revanche, pour un programme interactif, c'est-à-dire attendant les actions de l'utilisateur pour effectuer diverses opérations, le gain peut être substantiel, car le compilateur peut
fonctionner pendant que l'utilisateur consulte l'affichage. Pour un gain maximal, il faut
cependant que le programme soit conçu de telle façon qu'il soit chargé dans sa totalité dès le
début de l'utilisation afin de pouvoir être compilé en arrière-plan.
En effet, Java est conçu pour que les classes nécessaires au fonctionnement du programme soient chargées selon les besoins, cela afin d'optimiser ainsi les temps de chargement sur Internet en ne transmettant que les portions de code effectivement utilisées.
Java
15
eivd
Télécommunications
mjn
Par contre, pour bénéficier au maximum des avantages d'un compilateur JIT, il faut
autant que possible que le code soit téléchargé à l'avance afin d’être compilé, et cela sans
savoir si elles seront réellement utilisées. L'usage d'un compilateur JIT lorsque les classes
sont téléchargées à la demande se traduit le plus souvent par un faible gain de vitesse, voire
parfois un ralentissement de l'exécution. L’utilisation de classes comprimées (fichiers JAR)
peut en partie compenser cet inconvénient.
1.2.5
La machine virtuelle Java
Pour qu’un système informatique puisse exécuter un programme Java, il faut et il suffit
qu’il implémente la machine virtuelle Java (Java Virtual Machine JVM). Cette machine est
généralement intégrée dans un browser Internet comme Netscape 3, par exemple. De par sa
destination originale, la machine virtuelle a été conçue pour être de petite taille, si bien
qu’elle n’encombre pas excessivement les navigateurs par ailleurs surgonflés d’extensions
diverses.
La machine virtuelle exécute le code Java qui est, comme on l’a vu précédemment, un
code binaire, compilé. Ce code est appelé généralement Bytecode. Chaque instruction est
codée sur 8 bit, et peut prendre 0 ou plusieurs opérandes. Ce code est généré par le compilateur Java à partir d’un fichier source pour produire un ou plusieurs fichiers Java exécutables.
Il en résulte la structure illustrée à la figure 1.2, page 16 pour les applications écrites
pour la machine virtuelle Java.
FIGURE 1.2
Machine virtuelle Java et applications Java
WEB BROWSER (Netscape, Internet Explorer, ...)
JAVA virtual machine (JVM)
Applications Java
Système d’exploitation local (NT, Mac, UNIX, etc...)
L’évolution très rapide de Java fait que l’on a tendance actuellement (Sun, Apple, par
exemple) à considérer que la JVM doit plutôt être sortie du cadre du browser Internet et intégrée au système d’exploitation : cette modification fait qu’une application Java peut être exécutée en dehors du cadre d’Internet, et Java devient ainsi un langage de programmation à part
entière.
16
Java
eivd
1.2.6
Télécommunications
mjn
L’architecture de la machine virtuelle Java
La machine virtuelle Java (JVM) est une machine 32 bit, pouvant de ce fait adresser
jusqu’à 4 GB de mémoire. Cet espace mémoire comprend l’espace d’adressage des méthodes
(la zone où l’on va stocker le programme application), la pile, et la zone de mémoire dynamique. La MVJ ne dispose que de trois registres, contrairement à la tendance RISC, et travaille
essentiellement avec la pile. Toute opération sur des variables est effectuée au travers de la
pile. Cette architecture défavorable dans le cas d’une machine physique est particulièrement
bien adaptée à une machine virtuelle, et contribue à la simplicité de la MVJ.
La MVJ dispose comme principale originalité d’un “garbage collector” (littéralement
“collectionneur de déchets”, parfois appelé ramasse-miettes) qui gère les objets dynamiques
en mémoire. Contrairement à la plupart des langages où le programmeur doit s’inquiéter de
la gestion et de la destruction des objets que son programme crée en cours d’exécution, la
MVJ conserve la trace de tous les objets ayant été crées et détruit automatiquement les objets
n’étant plus référencés par l’application. Pour être réellement efficace, cette technologie doit
également restructurer périodiquement la mémoire pour éviter l’apparition d’un trop grand
nombre de “trous”, c’est-à-dire de zones mémoire libres, mais inutilisables parceque trop
petites. Ainsi, même si un programme libère globalement autant de mémoire qu’il en a occupée, l’effet de fragmentation de la mémoire peut aboutir à une impossibilité d’allocation
d’un nouvel objet parcequ’il n’existe pas assez de mémoire contigüe pour placer cet objet. Le
garbage collector évite cet effet en redisposant les objets en mémoire de manière à combler
les trous. Pour pouvoir intervenir efficacement, il est nécessaire de disposer d’un mécanisme
permettant de mesurer la fragmentation, et de déclencher le processus de restructuration
lorsque cette fragmentation paraît devenir critique.
L’opération effectuée par le garbage collector a l’avantage de libérer le programmeur
de bien des soucis, et de protéger les applications contre le phénomène de fragmentation de
la mémoire. Cette opération a en revanche l’inconvénient de ralentir encore davantage l’exécution de l’application, surtout au cours de la réorganisation automatique de l’espace
mémoire, opération qui peut intervenir à n’importe quel moment, sans que l’application
puisse se prémunir contre cette intervention. Les applications nécessitant un comportement
déterministe relativement au temps sont donc difficilement implémentables en présence d’un
tel mécanisme.
Java
17
eivd
1.3
Télécommunications
mjn
Caractéristiques de Java
Les caractéristiques de Java découlent directement du concept qui a été à la base de son
développement. Sun Microsystems résume les qualités de Java de la manière suivante, toute
modestie mise à part :
Java est un langage simple, orienté objets, distribué, interprété, fiable, sécurisé, indépendent de toute architecture, portable, de haute performance, multithreaded et dynamique.
Il convient de toujours garder à l’esprit que l’auteur de cette phrase est interessé à la
propagation du produit !
1.3.1
La simplicité de Java
Java se base sur C++ : quiconque sait programmer en C++ peut en moins d’un jour
écrire une applet Java non triviale. Malheureusement, C++ est un langage que l’on ne saurait
qualifier de simple. Java élimine donc de C++ tout ce qui est complexe. Parmi ces caractéristiques complexes que l’on a éliminées, citons notamment :
• Le préprocesseur
• Les fichiers en-tête
• L’arithmétique de pointeurs (et les pointeurs, par la même occasion)
• Les structures (implicitement contenues dans la notion de classe)
• Les unions
• L’héritage multiple
• L’héritage privé, ou héritage d’implémentation
• La surcharge d’opérateurs
• Les template (modèles, patrons); Java utilise un autre mécanisme pour implémenter la
généricité
De plus, pour épargner à l’utilisateur la difficulté de gestion de mémoire, Java comprend un gestionnaire de mémoire automatique (Voir L’architecture de la machine virtuelle
Java, page 17.), accompagné d’un “garbage collector” (parfois appelé “ramasse - miettes”).
Ceci devrait permettre au programmeur d’oublier les problèmes de destruction d’objets obsolètes.
1.3.2
Orientation Objets
Java est en fait plus “orienté objets” que C++, en ce sens qu’il est impossible de ne pas
programmer de manière “OO” avec Java, alors que l’on peut parfaitement programmer en
C++ comme on le faisait traditionnellement en C, de manière strictement procédurale.
18
Java
eivd
Télécommunications
mjn
Bien que strictement “OO”, Java comprend de fait moins de possibilités dans ce sens
que C++, puisque l’héritage multiple n’est pas supporté. Cette option est le résultat d’une
constatation très judicieuse de la part des auteurs de Java, qui montre que l’héritage multiple
n’est que très peu utilisé en pratique : dès lors, pourquoi en charger un langage dédié à un
créneau bien précis, pour lequel l’héritage multiple a encore moins de chances d’être utilisé1?
Le code et les données de l’utilisateur doit obligatoirement être réparti dans des classes.
Les seuls objets pouvant exister à l’extérieur de classes sont des types de base, comme des
entiers ou des booléens. Là encore, il s’agit d’une recherche de simplicité par rapport à
d’autres langages OO, comme Smalltalk, où les types simples n’existent pas.
En revanche, le fait de répartir le code dans des classes ne suffit pas à faire d’un programme un programme orienté objets; pour atteindre ce but, il faut que le programme soit
conçu de manière orientée objets, et cela, un langage de programmation ne peut y parvenir
seul.
1.3.3
Distribution
Java est un langage distribué, Sun Microsystems dixit. Le langage dispose pour justifier cette appellation de nombreuses caractéristiques, mais la principale est l’édition de liens
à l’exécution (late binding).
Les langages traditionnels ne permettent que malaisément l’utilisation de code non
défini, voire non disponible, à la compilation. Cette limitation rend difficile l’utilisation de
code non local, non situé sur la même machine que celle ayant servi au développement; elle
est imposée par la nécessité de fixer les adresses de manière statique, au moment du développement d’une application. Un langage distribué ne nécessite, idéalement, d’aucune phase
d’édition, voire de définition de liens. Cette particularité permet en théorie du moins l’utilisation de code inconnu au moment du développement de l’application.
En pratique, Java ne comporte pas de phase d’édition de liens, mais dans la majorité
des cas, les liens doivent être définis. Cette définition peut prendre plusieurs formes, la plus
simple étant le paquetage (package) que l’on importe sans toutefois le lier à l’application.
Ainsi, le paquetage peut résider sur un site distant de l’application au moment de l’exécution.
Dans ce cas, le compilateur connaît tout du code qu’il va utiliser, mais ne peut pas l’adresser
directement, car ce code n’est pas disponible durant la phase de compilation. Lors de l’exécution, il faudra recourir à des procédures particulières pour localiser, charger et exécuter le
code “étranger”. Ces procédures sont en principe partie intégrante de la machine virtuelle
Java, si bien que dans ce cas, l’utilisation de code non local au moment de l’exécution est
implicite. Corollairement, il devient possible de modifier ce code non local sans que l’application qui l’utilise en soit avertie (en d’autres termes, aie été recompilée).
Une étape supplémentaire, et fondamentale, est l’utilisation de code inconnu au
moment de la compilation, si ce n’est par le biais d’un service exporté. Java permet égale1. Si l’utilisation actuelle avait été d’emblée planifiée dans le cahier des charges du langage, il n’est pas certain que l’on eût
abouti aux mêmes options. Mais c’est là bien sûr pure spéculation...
Java
19
eivd
Télécommunications
mjn
ment de réaliser ce cas de figure; l’intérêt de cette possibilité réside dans la capacité que possède une application de s’adapter, au cours de son existence, à de nouvelles situations
(existence d’une nouvelle base de données, existence d’un nouveau central téléphonique,
etc...). Alors que les langages traditionnels nécessitent des auxiliaires souvent lourds pour
réaliser cette performance (CORBA, DCOM, par exemple), Java la réalise de façon naturelle, presque gratuite.
1.3.4
Le langage est interprété
Ce qui est présenté comme avantage par Sun Microsystems est une arme à double tranchant. S’il est vrai qu’un programme interprété est plus facilement transportable qu’un langage compilable -du moins en principe-, il est également plus lent, voire beaucoup plus lent,
en exécution.
La majeure partie des reproches faits à Java -à tort ou à raison- proviennent du caractère interprété de Java. Néanmoins, beaucoup des avantages de Java proviennent aussi du fait
du caractère interprété de Java. Quant à savoir si l’utilisation d’un langage interprété est,
dans l’absolu, un avantage ou un inconvénient... Voilà de quoi alimenter une guerre de religion supplémentaire.
Ceci dit, et comme nous l’avons déjà mentionné auparavant, dire que Java est interprété est un abus de langage : il est compilé pour une machine virtuelle. Même si l’on admet,
pour des raisons de facilité, cet abus de langage, il convient de bien garder à l’esprit la
nuance.
1.3.5
Fiabilité
Java est censé être plus résistant aux erreurs de programmation, parce qu’il est plus
simple (pas de manipulation de pointeurs, en particulier), et qu’il comprend un “garbage collector” dans l’environnement d’exécution. De fait, Java, grâce à sa simplicité, est mieux maîtrisé par les programmeurs, ce qui peut effectivement résulter en un nombre de fautes moins
grand. Le concept d’applet d’une part, et l’orientation objets d’autre part, limitent la taille des
segments de code sous Java, ce qui a pour résultat le développement d’objets plus petits, et
plus faciles à maintenir.
Le meilleur argument dans le sens de la fiabilité de Java est pourtant son caractère FOO
(Fanatically Object Oriented). Les langages orientés objets sont par construction susceptibles
de produire des exécutifs plus stables, plus faciles à tester et à dépanner.
Le caractère interprété de Java est également un atout dans ce sens : on peut imaginer
que l’interpréteur se livre à des test de cohérence avant de se livrer à une opération définie
dans le programme. Là encore, l’argument est à double tranchant: ces tests supplémentaires
ralentissent encore, si besoin est, l’exécution du code utilisateur.
Enfin, et relativement à C++ dont il est un descendant direct, Java permet, grâce au
“garbage collector” de ne pas se préoccuper de la gestion mémoire, et donc d’éviter les
20
Java
eivd
Télécommunications
mjn
défauts de mémoire1 (memory leaks) responsables d’un grand nombre de fautes en C++.
Cette caractéristique à elle seule rend le langage nettement plus fiable que C++.
1.3.6
Sécurité
Sun Microsystems a investi énormément dans la sécurité de Java, et si cette sécurité
n’est pas encore complètement démontrée, elle est néanmoins mise en avant par le concepteur du langage.
L’interpréteur Java constitue une “coquille” (une machine virtuelle) dans laquelle le
programme Java s’exécute. En théorie, le programme Java ne pouvant s’exécuter que sur la
machine virtuelle, il semble difficile, voire impossible au programme de toucher si peu que
ce soit la machine réelle. Au pire, un programme particulièrement malveillant (ou particulièrement mal conçu) pourrait détruire la machine virtuelle Java, mais ne devrait pas pouvoir
compromettre l’intégrité de la machine réelle abritant la machine virtuelle. En pratique,
l’expérience montre que si les concepteurs de systèmes de sécurité investissent énormément
d’efforts pour “fiabiliser” leurs produits, il n’y a guère de systèmes à l’abri d’attaques malveillantes, à plus ou moins brève échéance. Néanmoins, et dans les limites de l’expérience de
l’auteur, il n’existe pas actuellement de choses plus sûres sur Internet à l’heure actuelle
qu’une applet Java2.
1.3.7
Indépendance de l’architecture et portabilité
Cette affirmation repose intégralement sur le fait que Java est interprété. L’idée est que
pour autant que l’interpréteur soit porté sur une machine donnée, sous un système d’exploitation donné, une applet Java pourra s’exécuter sur ce système. En théorie, cette affirmation est
indiscutable. En pratique, on se souvient qu’une affirmation analogue a déjà été faite quelque
vingt ans plus tôt3 - et à d’autres occasions d’ailleurs - et ne s’est pas vérifiée dans le long
terme.
1.3.8
Performances
Parler de performances au sujet d’un langage interprété est toujours délicat. Lorsque
Sun Microsystems prétend que Java est aussi efficace que C++, il est difficile d’y voir autre
chose qu’une vague manoeuvre publicitaire. De fait, certaines mesures indépendantes chiffrent Java à un taux de performances de 2 à 35 fois inférieur à celui de C++ pour un code
comparable. Les principaux points faibles de Java proviennent du concept de machine virtuelle utilisé, et du mécanisme d’héritage implémenté. La machine virtuelle ne permet pas
1. Il se trouve que certaines situations peuvent empêcher Java de reconnaître un objet inutile, ce qui conduit finalement
aussi à un "memory leak".
2. Un bug célèbre qui “permet” de détruire Windows 95 et 98 et qui provoque une erreur fatale de l’explorateur sous Windows NT 4 est dû à une applet Java. Le problème provient du fait que Microsoft a voulu “améliorer” Java en autorisant
l’accès direct aux fonctions de DirectX, ce qui n’est pas prévu par la spécification du langage...
3. L’université de Californie, à San Diego, avait fabriqué un compilateur Pascal selon les principes de Niklaus Wirth, et qui
se fondait sur un interpréteur de "pseudo-code" (p-code). Le code objet pouvait en théorie être interprété sur n’importe
quelle machine. En pratique, l’interpréteur ne fut porté que sur les PC 8088 et les Apple II, et sa portabilité était douteuse.
Java
21
eivd
Télécommunications
mjn
d’appel direct de procédures, mais requiert une indirection afin de s’assurer que l’espace de
la machine virtuelle n’est pas dépassé : cette indirection demande du temps d’exécution supplémentaire à chaque appel. Lors de l’héritage, il est de plus nécessaire de chercher si une
méthode donnée n’est pas surchargée par une méthode dérivée; le mécanisme utilisé par Java
dans ce cas est, pour des raisons de sécurité et de compatibilité avec la machine virtuelle
Java, très lourd et de ce fait très gourmand en temps d’exécution. Le mécanisme de "garbage
collection" n’améliore pas les choses...
En résumé, Java ne saurait être qualifié de performant relativement à des langages
compilés traditionnels. En revanche, pour un langage interprété, Java est étonnamment performant. L’introduction de compilateurs natifs pendant le téléchargement d’une part (Just In
Time Compiler) et de puces implémentant la machine virtuelle Java d’autre part devrait améliorer le bilan de Java dans le futur.
1.3.9
Multithreaded
Un des aspects les plus intéressants de Java, outre son orientation résolument objets,
est la possibilité de générer des unités d’exécution multiples, ou threads. L’utilisation de
threads permet l’exécution quasi-simultanée d’un même code plusieurs fois. Contrairement
aux "processus" que l’on rencontre dans les systèmes d’exploitation multi-tâches, les threads
partagent tous le même espace mémoire.
La possibilité d’utiliser plusieurs unités d’exécution peut simplifier notablement le travail du programmeur dans certains cas, lorsque deux (ou plus) actions sont nécessaires
simultanément. Un exemple pourrait être l’affichage d’une animation complexe et l’interrogation simultanée du clavier et de la souris pour savoir si l’utilisateur ne désire pas interrompre l’animation.
Ici encore, le caractère interprété de Java peut représenter un inconvénient par rapport
aux performances d’un langage compilé comme C++, pour lequel existent bon nombre de
librairies implémentant des threads de manière très performante relativement à Java. Mais
contrairement à Java, ces librairies sont presque toujours liées au système d’exploitation, et
donc non portables, même au niveau du code source.
1.3.10
Le caractère dynamique de Java
Java a été conçu pour supporter des changements fréquents, comme on les connaît dans
l’environnement du Web. A ce point de vue, on peut dire que Java est dynamique. Le développement d’un programme Java ne comprend pas de phase d’édition de lien au sens où on la
comprend en C++. Les références à des classes externes ne sont résolues qu’au moment de
l’exécution.
On met souvent cette caractéristique en exergue comme avantage de Java relativement
à C++ qui fonctionne sur le principe de l’édition de liens en phase de développement de
l’application. Cet avantage est à double tranchant; s’il est vrai qu’il n’est pas nécessaire de
modifier l’application pour bénéficier d’une nouvelle version d’une librairie Java existante,
ce caractère dynamique implique également que l’on n’a pas le contrôle sur l’apparition de
22
Java
eivd
Télécommunications
mjn
nouvelles versions de librairies Java utilisées, ce qui peut parfois conduire à des comportements aberrants pour l’utilisateur. Cet inconvénient existe bien sûr en C++ également, mais
du fait de l’obligation de repasser par l’étape d’édition de liens et de distribution, le programmeur a l’occasion de constater lui-même d’éventuelles incompatibilités avec une nouvelle
version de la librairie utilisée. Un réel avantage, par contre, est de pouvoir bénéficier de nouvelles versions plus performantes de la MVJ sans toucher à l’application elle-même, ce qui
n’est pas possible avec un langage comme C++ ou Ada.
Java
23
eivd
1.4
Télécommunications
mjn
Le problème de sécurité posé par Java
Exécuter une application provenant d’une source inconnue sur un ordinateur est considéré comme une entreprise à risques, quelles que soient les circonstances. L’histoire pourtant
courte de l’informatique est déjà riche d’anecdotes et de récits de catastrophes dûs à des programmes malveillants. Que dire alors d’une technologie dont on n’est peut-être même pas
conscient qu’elle exécute des applications sur son ordinateur, ni quelle application elle est en
train d’exécuter ? Il devrait être facile, avec une technologie de ce type, de fabriquer des
applets qui détruisent des fichiers, formattent des disques, voire consultent les mots de passe
de l’ordinateur hôte et en transmettent la liste exhaustive à l’auteur du programme1!
Il est donc indispensable, pour populariser un tel produit, de garantir sa sécurité aussi
bien que possible. De ce fait, de sévères restrictions sont imposées aux applets. Ces restrictions limitent l’utilisation du langage pour la conception d’applications réelles, aussi a-t-on
défini, parallèlement aux applets, des applications Java non soumises aux restrictions valables pour les applets; en revanche, une application Java ne peut pas circuler sur le réseau.
Une application Java ne se distingue pas, dans son aspect commercial, d’une application C++
ou Ada.
La “coquille” Java dont nous avons déjà parlé confine l’applet dans la machine virtuelle, et interdit théoriquement à l’applet tout accès à la machine réelle. Un code “malicieux” ne peut donc théoriquement que détruire la machine virtuelle; par rapport à une
protection conventionnelle de type “anti-virus”, cette approche est nettement plus sûre,
puisqu’elle ne dépend pas de mises à jour périodique du programme de contrôle, et qu’elle ne
peut être désactivée. De plus, plusieurs composants de l’environnement d’exécution de Java
contribuent à améliorer la sécurité, et à protéger la machine virtuelle elle-même contre des
attaques insidieuses.
1.4.1
Le chargeur de classes (class loader)
Lors du téléchargement d’une applet, le browser fait intervenir le chargeur de classes
pour initialiser l’applet au sein de l’espace mémoire de la MVJ. La chargeur place le code
exécutable de l’applet dans l’espace mémoire de la MVJ, et ce faisant, contrôle la cohérence
de l’adressage et des références de l’applet.
1.4.2
Le vérificateur (class checker)
Le vérificateur est invoqué immédiatement après le chargement, et permet de contrôler
la cohérence de l’espace d’adressage de l’applet. En principe, le vérificateur devrait être en
mesure de déterminer si une applet va tenter d’adresser de la mémoire en dehors de la zone
reservée à la MVJ.
1. Ce qui a effectivement été réalisé avec une technologie de ce type par un pirate informatique. Avant la finalisation de
Java, d’autres avaient déjà eu l’idée d’applications téléchargeables, et ils utilisaient Tcl/Tk comme outil, nettement moins
sécurisé que Java.
24
Java
eivd
Télécommunications
mjn
Le vérificateur devrait aussi être en mesure de prévoir d’éventuelles incompatibilités
entre l’applet et l’implémentation locale de la MVJ. Il se peut que l’implémentation locale ne
dispose pas assez de mémoire physique pour exécuter une applet donné : le vérificateur
devrait en principe pouvoir détecter cette incompatibilité et donner un avertissement en conséquence à l’utilisateur.
1.4.3
Le policier (security agent), Security Manager
Lorsque la MVJ constate une tentative d’une applet de violer les règles de “bon comportement”, elle en réfère à un “policier” qui arbitrera le dilemme de la MVJ, et décidera si
l’applet en question peut être autorisé à effectuer une opération ou non. Cette opération litigieuse peut consister en une tentative d’ouvrir un fichier, ou d’effectuer une connexion
réseau; plus généralement, toute tentative de l’applet de communiquer avec l’extérieur devra
passer par ce policier.
Le policier est extérieur à la MVJ proprement dite. Il est généralement partie intégrante
du browser utilisé; on peut penser qu’il devrait dans un proche avenir être intégré au système
d’exploitation.
1.4.4
Elements du langage renforçant la sécurité
Le langage a été d’emblée pensé en fonction du problème de la sécurité, et certaines
“améliorations” de C++ (ou présentées comme telles) sont plus vraisemblablement des contraintes imposées par des critères de sécurité. Ainsi, l’interdiction d’utilisation de pointeurs
au sens C++ du terme est presque obligatoire si l’on désire s’assurer qu’une application ne
tente pas d’adresser de la mémoire de manière illicite (par exemple, pour modifier la MVJ).
L’argument selon lequel Java est plus sûr parceque plus simple est à considérer avec
quelque précaution. L’un des logiciels les plus gros et les plus fiables du monde a été écrit
avec un langage quasi abandonné depuis, parce que beaucoup trop complexe. Par contre un
des plus catastrophiques virus de l’histoire d’Internet a été écrit en quelques lignes d’un langage interprété, ne connaissant pas de pointeurs, ni de goto ou d’exceptions. Le langage peut
être un élément de sécurité, mais il n’en est jamais un élément déterminant.
1.4.5
Java, sûr ?
Java est un langage aussi sûr que l’on peut le réaliser dans le cadre d’Internet, par
ailleurs complètement étranger dans sa conception à la notion de sécurité. Il est actuellement
beaucoup plus sûr de télécharger une applet Java que de passer commande sur Internet en
donnant son numéro de carte de crédit; la transaction par carte de crédit est rarement sécurisée, et quand elle l’est, c’est souvent de manière approximative.
Java est sûr jusqu’à ce que quelqu’un découvre une faille, ce qui finira forcément par
arriver. Il n’existe pas de sécurité absolue dans quelque domaine que ce soit, à moins d’éviter
complètement d’utiliser le domaine en question. Il n’y a pour l’instant pas de raisons de
renoncer aux possibilités offertes par cet outil.
Java
25
eivd
Télécommunications
mjn
La version 1.03 de la MVJ est considérée par beaucoup comme insuffisamment protégée. Une nouvelle version de la MVJ (1.1) est apparue au cours de l’année 1997, qui corrige
certains des principaux reproches faits actuellement à la MVJ. L’intérêt de Java est que l’on
devrait pouvoir corriger ainsi les défauts de sécurité de la MVJ et conserver la compatibilité
intégrale avec tous les applets et applications existantes.
Au moment de l’écriture de ces lignes, la version la plus récente, et faisant référence de
la MVJ est la version 1.3.
1.4.6
Java, a Windows killer ?
On parle beaucoup de Java comme d’un adversaire de Windows, et d’une arme inventée par Sun contre Microsoft et sa quasi hégémonie dans le monde du logiciel. Il y a probablement une part de vérité dans cette affirmation, mais Java va au-delà d’une simple guerre
d’interfaces utilisateurs. Java introduit une nouvelle manière de concevoir des environnements distribués, et c’est à ce niveau que se situe le véritable danger pour des éditeurs de
logiciels comme Microsoft, qui prônent le concept suranné d’architectures fermées, basées
sur un seul matériel et un seul système d’exploitation.
Java, considéré par certains comme un aimable amusement tout juste bon à animer des
logos sur des pages du Web, pourrait représenter une révolution majeure en permettant à tout
un chacun d’utiliser des applications performantes indépendemment de la machine et du système d’exploitation utilisé. Si toutes les applications intéressantes sont écrites en Java, peu
importe le système d’exploitation ou la machine: il suffit qu’elle implémente une machine
virtuelle Java.
En revanche, Java a encore du chemin à faire pour parvenir à la performance de systèmes comme Windows, ou l’interface utilisateur du Macintosh ou de NextStep. L’Abstract
Window Toolkit est, dans son implémentation actuelle, peu fiable et limité. La sécurité, bien
qu’ayant fait l’objet d’efforts particuliers, doit impérativement être améliorée. La performance est peu satisfaisante. Les environnements de développement sont encore immatures (à
l’exception notable du JDK de Sun, qui a de plus l’avantage d’être gratuit). Les classes
Swing, introduites à partir de la version 1.2 de Java, montrent que les concepteurs de Java
sont conscients du problème, et apportent des solutions.
26
Java
eivd
1.5
Télécommunications
mjn
Implémentation matérielle de la machine
virtuelle Java
Le principal inconvénient de la machine virtuelle Java est d’être ... virtuelle, c’est-àdire de devoir être émulée sous forme logicielle par un CPU d’une autre famille, comme un
80x86, ou un Power PC. La performance des applications Java s’en trouve grandement pénalisée par rapport à celle que l’on peut attendre de la part d’applications natives, c’est-à-dire
développées pour le CPU autour duquel l’ordinateur hôte est construit.
Sun Microsystems entend remédier à cet état de fait par deux approches simultanées,
compatibles entre elles :
• Le coprocesseur Java
• L’ordinateur Java
Le principe de base de ces deux approches est identique. A partir de la spécification de
la machine virtuelle, il est possible en principe d’implémenter une machine réelle parfaitement conforme à la spécification. Cette machine réelle est dès lors à même d’exécuter directement le “bytecode” Java, sans opération d’interprétation intermédiaire, et de ce fait de
rivaliser avec des applications écrites en C et en C++ pour des machines natives.
1.5.1
Le coprocesseur Java
Le coprocesseur Java est un chip (une carte, le plus souvent) qui peut se glisser dans un
emplacement libre d’un PC (actuellement, une station Sun SuperSPARC), et se mettre à disposition d’une application requérant une interprétation de code Java (typiquement, un viewer
WWW comme Netscape).
En principe, dès que Netscape (ou le viewer utilisé) détecte un lien sur une applet Java,
il va télécharger le code de l’applet non pas dans sa propre machine virtuelle, mais sur la
carte coprocesseur, donc dans la machine réelle. L’applet va alors s’exécuter entièrement sur
le coprocesseur, délivrant ainsi une performance théoriquement beaucoup plus intéressante
pour l’utilisateur.
En pratique, cette manière de faire se heurte à de nombreuses difficultés, en raison de la
nécessité d’accéder à des portions communes d’écran (ou d’autres ressources) depuis deux
applications séparées, s’exécutant dans des environnements matériels séparés. Cette condition est souvent difficile à réaliser sur des systèmes d’exploitation multi-tâches préemptifs,
qui intégrent des mécanismes de protection mémoire destinés justement à éviter ce genre
d’opérations.
1.5.2
L’ordinateur Java
L’autre alternative est l’ordinateur Java, dont le seul processeur est constitué du CPU
Java. Les applications doivent donc être recompilées pour s’accomoder de ce CPU.
Java
27
eivd
Télécommunications
mjn
L’ordinateur Java a l’énorme inconvénient de ne pouvoir exécuter les applications existantes sans adaptation (recompilation). D’autre part, les applications existantes sont écrites
pour le langage C ou C++ (langage pour lequel sont optimisés les chips habituels), ce qui
peut laisser craindre une certaine dégradation de performances sur un processeur optimisé
pour Java. En fait, ce dernier argument n’est pas critique, tant il est vrai que Java est par
beaucoup d’aspects un sous-ensemble de C++. Le seul handicap de Java, lorsqu’il exécute
des programmes C, est la présence du “garbage collector” qui va freiner inutilement le déroulement d’un programme prévu pour un fonctionnement sans réallocation automatique de la
mémoire.
L’ordinateur Java est intéressant parce qu’à l’instar du langage, il est peu gourmand en
ressources pour des performances plus qu’acceptables. On peut utiliser l’ordinateur Java
dans le cadre d’applications de petites dimensions, sans périphériques coûteux et mémoire
considérable. Il constitue une base idéale, semble-t-il, pour le “Network Computer” (Voir Le
“web Computer”, page 34.).
1.5.3
Java en tant que plate-forme
A côté du langage de programmation, certes intéressant, mais pas vraiment révolutionnaire, se profile l’aspect plate-forme de Java. Contrairement à C++, on a avec Java d’emblée
mis l’accent sur une bibliothèque aussi riche que possible. Au fil du temps, cette bibliothèque
est devenue incroyablement diversifiée, si bien que l’écriture d’une application Java se
résume souvent à l’assemblage de composants localisés ça et là sur Internet.
Mieux, l’introduction de la notion de composants distribués (Java Beans) rend Java
idéal pour les applications de télécommunications et de téléinformatique. On trouve actuellement des composants fiables pour toutes sortes d’applications. Conjugués avec le mécanisme
de distribution de code de Java, RMI (Remote Method Invocations), ces composants permettent le déploiement aisé et bon marché d’applications sur un réseau de télécommunications.
Les paquetages java.net (réseau), JTAPI (Java Telephone Application Programming
Interface), RMI déjà mentionné et JAIN (Java API for Intelligent Networks), entre autres,
offrent des interfaces abstraits très performants avec les applications de zélécommunications.
Enfin, il y a JINI (acronyme sans signification particulière avouée) qui se profile comme un
fantastique mécanisme d’implémenter des fonctionnalités “plug and play” (brancher et utiliser) au niveau du réseau.
Les télécommunications, bien que privilégiées pour des raisons assez évidentes dans
l’offre Java, ne sont pas, et de loin, le seul thème abordé par la plate-forme Java. Il serait fastidieux de faire une énumération exhaustive ici, mais nous citerons quand même
• JDBC, Java Database Connectivity. Une extension permettant la connexion avec de nom-
breuses variantes d’implémentation à une base de données SQL.
• JCE, Java Cryptography Extensions
• JMF, Java Media Framework
• JRTE, Java Real Time Extensions
28
Java
eivd
Télécommunications
mjn
• Java 3D, paquetage pour les applications de modelage en 3D, avec interfaçage à VRML
(Virtual Reality Modeling Language).
Le but poursuivi ici est évident : il s’agit d’offrir une alternative à Windows, alternative
qui serait portable sur tout système d’exploitation (en particulier Windows) ou machine pour
lequel il existe une machine virtuelle Java. Cette alternative n’est pas réellement une attaque
contre la quasi hégémonie de Windows (attaque qui en l’état actuel des choses serait probablement suicidaire), mais plutôt une recherche de complémentarité; l’argument de Sun est le
suivant : utilisez Windows et les applications de la suite Office si vous en avez besoin, mais
disposez en parallèle d’applications portables, qui pourront au besoin migrer sur Linux ou
SunOS.
Microsoft a ressenti Java comme une attaque contre son hégémonie. Il a d’emblée contesté l’appelation de plate-forme à Java, pour le reléguer au rôle de simple langage de programmation, pas meilleur (et certainement moins puissant) que C++ pour programmer
Windows par le biais des MFC. Ensuite, il s’est ingénié à définir des versions de Java spécialement adaptées à Windows, afin de nuire à sa portabilité. Enfin, il a été jusqu’à interdire
l’utilisation de Java sur les sites Internet qu’il contrôle. Ces faits, ainsi que le soutien apporté
par IBM, Oracle et d’autres à la technologie Java constitue une indication sur les potentialités
de Java : malgré une indicutable immaturité, Java constitue la première véritable évolution
informatique depuis longtemps. Java permet de considérer une application non plus comme
s’exécutant sur un ordinateur composé d’un ou plusieurs CPU, d’une mémoire et d’un stockage permanent, mais distribuée sur un réseau hétérogène d’ordinateurs. La technologie
équivalente de Microsoft, DCOM, reste confinée au monde Windows1.
Dernière trouvaile du géant de Seattle, C# est un langage de programmation dont
DCOM est une partie intégrante. Du fait de l’orientation distribuée de ce langage, il se pose
comme rival direct à la technologie Java. En revanche, il n’est pas portable, et sa distribution
actuelle (2000) est tout à fait confidentielle.
1. Des portages ont été tentés sur diverses versions de UNIX par Software AG, par exemple. Ces portages nécessitent des
fonctions passerelle. Il existe assi des passerelles avec la technologie CORBA; enfin, bien que non normalisées, il existe
diverses passerelles DCOM - Java disponibles gratuitement ou moyennant un coût modeste sur Internet.
Java
29
eivd
1.6
Télécommunications
mjn
JavaScript1
En 1995, Netscape Communications envisage de créer lui aussi un langage “pour le
Web”, qui sera un langage interprété, un langage de script. Ce langage s’appellera LiveScript. Un peu plus tard, Netscape signe un accord avec Sun Microsystems pour la technologie Java, et s’empresse de rebaptiser son enfant en JavaScript.
JavaScript n’a en commun avec Java qu’une partie du nom. Il s’agit d’un macro-langage destiné à améliorer l’interactivité d’une page Web de manière simple. Dans ce contexte,
on peut dire que JavaScript est une réussite technique; il est en revanche difficile actuellement de parler de réussite économique.
JavaScript est une alternative efficace à l’utilisation du “Common Graphics Interface”
(CGI, ou cgi-bin pour certains), mais l’apprentissage de CGI est relativement complexe
par rapport à celui de JavaScript qui permet par contre plus de choses.
1.6.1
Utilisation de JavaScript
Pour effectuer des besognes simples, JavaScript est incomparablement plus simple que
Java. Afficher l’heure et la date en JavaScript se fait en une ligne, dans le corps même de la
page HTML :
<SCRIPT>
document.write(“La date et l’heure courante sont : “+Date())
</SCRIPT>
Par comparaison, une implémentation Java peut paraître complexe, même sans considérer qu’il faudra encore référencer le fichier .class dans le fichier HTML (le fichier
.class ne peut pas être inclus dans le fichier HTML) :
import
import
public
java.util.Date;
java.awt.Graphics;
class
DateTime extends java.applet.Applet
{
public
void
init()
{
resize(150, 25);
}
public
void
paint(Graphics g)
{
Date today = new Date();
g.drawString(“La date et l’heure courante sont : “+
today, 50, 25);
}
};
1. Il existe un cours du même auteur qui décrit entre autres JavaScript. Ce cours est consacré aux divers outils existant sur
Internet, et présente également HTML, CGI, e-mail, telnet et ftp, par exemple.
30
Java
eivd
1.6.2
Télécommunications
mjn
Développement de script JavaScript
Le script JavaScript peut être inclus au sein de la page HTML, entre les commandes
<SCRIPT> et </SCRIPT>. Il est donc en principe édité en même temps que la page
HTML, et utilise les mêmes ressources (WinEdt, SimpleText, vi, etc...) que celles nécessitées
par l’édition de la page HTML.
Il est en revanche difficile de trouver des sites exportant des scripts en tant que tel. On
peut néanmoins repiquer des fragments de page HTML en utilisant l’option “View Source”
du browser utilisé. Là encore, il peut y avoir des droits d’auteur à respecter : dans ce cas, ils
devraient être spécifiés dans le cadre du script, sous forme de commentaires.
Par ailleurs, JavaScript peut utiliser Java, ce qui en fait un langage plutôt complémentaire à Java que concurrent.
Java
31
eivd
1.7
1.7.1
Télécommunications
mjn
Et les autres outils ?
VBScript
VBScript est la réponse de Microsoft à l’offensive Java1. Il s’agit ni plus ni moins que
d’une version supplémentaire de Visual Basic, adaptée aux exigences d’Internet, donc comprenant quelques instructions et possibilités supplémentaires. Ce langage de script convient
particulièrement bien aux habitués des applications de la suite Office du même éditeur, puisque les langages “macro” des divers composants de la suite sont également des dérivés de
Visual Basic. Le passage de Visual Basic for Excel à VBScript (par exemple) est particulièrement aisé.
De par ses fonctionnalités et ses possibilités, VBScript est comparable à JavaScript; les
éventuels avantages de VBScript relativement à JavaScript sont de nature propriétaire, et liés
aux technologies propres de Microsoft (en particulier ActiveX). VBScript est donc de caractère moins universel que Java, ou JavaScript.
1.7.2
CGI
Le Common Gateway Interface (CGI) constitue la première tentative pour offrir un peu
d’interactivité à une page Web. Il ne s’agit en fait pas d’un modèle de programmation, mais
plutôt d’un interface entre le client et le serveur. Le client peut, au travers de CGI, exécuter
des commandes avec des paramètres sur le serveur. Les programmes sur le serveur peuvent
en principe être écrits en n’importe quel langage, mais on utilise souvent des scripts perl sur
les serveurs UNIX.
Windows 2000 inclut un interpréteur perl dans la livraison du système d’exploitation.
Par ailleurs, ce langage est disponible gratuitement.
L’interactivité offerte par CGI est relativement faible, puisque toutes les actions nécessitent une intervention du serveur, et donc une connexion HTTP. L’avantage de cgi est que,
comme tout est réalisé sur le serveur Web, et que les résultats sont communiqués en HTML,
cgi est donc forcément portable.
1.7.3
Dynamic HTML (DHTML, DNA)
Les techniques dites HTML dynamiques sont récentes (fin 1997) et constituent une
autre facette de la guerre Microsoft - Java. Ces techniques sont en principe introduites par
Microsoft pour rendre inutile l’utilisation de Java. Il est possible, grâce à ces techniques, de
répondre de manière plus ou moins dynamique aux actions de la souris, par exemple, en
1. Ce n’est pas la seule réponse, d’ailleurs, la plupart étant de nature non technique. Ainsi, Microsoft a, fin 1997, pratiquement mis hors la loi Java dans les sites Web contrôlés par le géant de Redmont. Incidemment, cela tend à démontrer
l’intérêt de Java, et le danger (réel ou imanginaire) pour Microsoft : il faut que l’ennemi fasse peur pour que l’on se sente
obligé d’utiliser de pareils moyens. Voila qui devrait en fait constituer une publicité certaine pour Java !
32
Java
eivd
Télécommunications
mjn
changeant l’aspect d’un bouton, en modifiant une image, etc... Ces techniques sont encore
immatures, et non supportées par l’ensemble des navigateurs.
Java
33
eivd
1.8
Télécommunications
mjn
Perspectives
Java est un pas important vers un système informatique réellement distribué, et donc
vers une nouvelle approche de l’informatique. En principe, il suffirait de disposer d’un ordinateur capable d’effectuer une connexion avec le réseau, et de télécharger aussi bien le système d’exploitation que les applications depuis le réseau. Pratiquement, la vitesse de
communication insuffisante reste le seul frein à cette tendance.
Cette limitation peut se combattre par nombre de moyens, les réseaux B-ISDN ou les
connexions xDSL n’étant que quelques exemples. La multiplication du nombre de serveurs
peut, de manière encore plus efficace, contribuer à la solution. On obtiendrait ainsi une nouvelle vision de l’informatique, beaucoup plus liée à la communication, et de fait aux télécommunications, puisque le système d’exploitation ne serait plus une option que l’on prend à
l’achat d’une machine, mais une option que l’on décide à l’enclenchement de l’ordinateur,
instant correspondant à la connexion au réseau.
Ces possibilités posent nombre de problèmes politiques et juridiques qui sont encore
loin d’être résolus : il suffit de constater la quantité de problèmes posés par le seul Internet
pour s’en rendre compte. Mais le fait que des problèmes existent n’empêche pas d’y trouver
des solutions...
1.8.1
Le “web Computer”
Le Web Computer est l’une des possibilités envisagées pour permettre de faire baisser
encore le prix des ordinateurs. Le Web Computer est un appareil de très bas prix (ordre de
grandeur < 500 $), sans véritable système d’exploitation, ne possédant que les ressources
nécessaires pour télécharger le système d’exploitation depuis Internet. Ses seules applications locales sont une machine virtuelle java,ou un chip exécutant Java en mode natif (Voir
L’ordinateur Java, page 27.), et les protocoles nécessaires (PPP / SLIP, IP, TCP/IP) pour
accéder au serveur qui lui fournira son système d’exploitation.
Cette machine a de nombreux avantages conceptuels :
• Son système d’exploitation est toujours actualisé.
• Il n’est plus nécessaire de disposer de machines équipées de disques volumineux, diffici-
les à sauvegarder, puisque les applications ne résident plus localement.
• Les fichiers utilisateurs peuvent résider sur le serveur, moyennant finance modique sur la
base du mégabyte occupé, par exemple. Les problèmes de sauvegarde sont réglés par le
serveur.
• Les applications sont toujours actualisées. Au lieu de payer relativement cher une application peut-être rarement utilisée, on peut imaginer payer l’utilisation de cette application
sur la base du temps d’utilisation effective.
• La necessité de télécharger les applications impose la définition de petites applications
modulaires (objets) pouvant se combiner pour offrir des fonctionnalités équivalentes aux
brontosaures actuels.
34
Java
eivd
Télécommunications
mjn
Cette machine présente aussi quelques problèmes :
• Il n’est pas évident de faire naître le besoin de ce type de machines dans un marché déjà
hyper-tendu.
• La machine est vulnérable; la moindre panne de réseau la rend totalement inutilisable.
• Le succès d’une telle machine est lié aux applications que peut offrir le réseau. Cette offre
est à son tour limitée par les possibilités du réseau.
• Le prix déjà outrageusement bas des PC de bas de gamme rend l’avantage de prix parfois
discutable.
La seule manière pour le Web Computer de s’imposer est d’offrir une gamme de services beaucoup plus étendue, et d’utiliser à fond l’atout du réseau. L’existence implicite du
réseau dans un ordinateur permet d’imaginer une symbiose beaucoup plus grande de l’informatique et des télécommunications : pourquoi acheter un fax séparé ? Pourquoi utiliser
encore le courrier écrit; pourquoi ne pas concevoir une association symbiotique entre courrier électronique, fax, terminal bancaire, échange de documents multimédia et téléphone
classique ? Un seul terminal peut sans autre remplir ces diverses tâches de manière intégrée,
et c’est le Network Computer (NC).
FIGURE 1.3
Le Network Computer, tel qu’il pourrait être
Network Computer
Service téléphonique
Interface réseau
ISDN,
ATM, etc...
Web surfer
Fax
Terminal bancaire
Visiophonie
Consultation de bases de données
Services multimédia
Mais le principal obstacle à une apparition d’un véritable Web Computer reste Microsoft. Le principe qui veut que Windows doit tout contrôler, depuis les téléphones portables
jusqu’aux serveurs d’entreprises rend un Web computer basé sur Java insupportable; Micro-
Java
35
eivd
Télécommunications
mjn
soft a de ce fait introduit le Web PC, un outil hybride entre un PC et un raccordement Internet, mais qui n’a pas obtenu de succès parce que justement il n’apportait aucun service
nouveau relativement à un PC. Le Web PC a quand même eu le mérite (?) de tuer dans l’oeuf
les développements concernant le Web Computer; il faudra vraisemblablement attendre des
progrès significatifs de la part des télécommunications (largeur de bande) pour relancer le
débat. Mais ces progrès sont déjà là (UMTS, réseaux satellites, etc...); il suffit désormais de
les exploiter.
Une opportunité majeure pour le succès de Java réside peut-être dans l’informatique
mobile. Les principaux acteurs des réseaux de télécommunications s’intéressent à Java,
même si la plupart continuent à utiliser une technologie centrée sur Windows. IBM et Alcatel, pour ne citer que ces deux protagonistes, ont introduit Java dans leurs centraux de téléphonie et de téléinformatique, respectivement.
36
Java
eivd
1.9
1.
2.
3.
4.
5.
6.
7.
8.
9.
Télécommunications
mjn
Test : Le concept Java
Pourquoi un exécutable Java (bytecode) est-il dit “multi-plateformes”?
Qu’est-ce que JavaScript par rapport à Java ?
Comment est garantie la sécurité des applets Java, et quels sont les outils mis à disposition
pour combattre les pirates informatiques ?
Y a-t-il des inconvénients à utiliser Java pour la programmation d’applications courantes,
et y a-t-il des avantages relativement à, par exemple, C++ ou Ada ?
Existe-t-il des domaines d’applications où Java est malaisément utilisable, quelle que soit
par ailleurs la puissance de la machine utilisée?
Un chip Java pourrait-il exécuter du code objet C++ de manière efficace?
Steve Jobs a, dans une conférence de presse, émis la possibilité de réécrire NextStep, ainsi
que le noyau sous-jacent, pour le Macintosh en Java. Quels seraient les avantages d’une
telle stratégie, et quels en seraient les inconvénients (indépendemment de la vitesse d’exécution) ?
Pourquoi ne pas avoir opté pour un interpréteur source pour implémenter Java, au lieu
d’une machine virtuelle?
Etant donné que plus de 80% des machines actuelles sont des machines basées sur des
processeurs de Intel, ou compatibles, on pourrait argumenter que les 20% restant ne suffisent pas à justifier l’introduction de Java en tant que langage “multi-plateformes”. Cette
affirmation vous paraît-elle justifiée?
Java
37
eivd
38
Télécommunications
Java
mjn