La capacité à exécuter une application Java sur une plate-forme donnée est obligatoirement conditionnée par l'existence d'une implémentation de la Machine Virtuelle Java (ou JVM, Java Virtual Machine en anglais) sur cette dite plate-forme. Ce chapitre présente le rôle et le fonctionnement interne de la JVM.

Nous avons vu, dans le chapitre précédent, qu'un compilateur Java générait un fichier .class contenant des bytecodes ou P-codes (P pour Program). Ces bytecodes ne peuvent pas être exécutés tel quels par le processeur de la machine sur laquelle on désire lancer un programme Java compilé. Il est nécessaire d'introduire une couche logicielle ayant pour principale fonction de traduire les bytecodes en instructions exécutables par le processeur de la machine hôte. C'est cette couche que l'on appelle la Machine Virtuelle Java (JVM). On peut donc dire que, porter Java sur une plate-forme, c'est simplement porter la machine virtuelle Java. Sun propose d'ailleurs sur son serveur web une spécification très précise destinée aux développeurs voulant effectuer un tel portage.

La JVM est en fait l'implémentation d'un processeur virtuel, disposant d'un jeu d'instructions propres. Chaque instruction est codée sur un octet et il en existe environ 200 actuellement. Ce nombre peut paraître important, à première vue, mais en fait les concepteurs de Java ont défini plusieurs instructions faisant les mêmes opérations mais pour des types de données différents (entier, réel, etc.).

Le jeu d'instructions de la JVM comporte un certain nombre d'instructions classiques, comme les opérations arithmétiques, logiques et les sauts conditionnels. Cependant, le processeur virtuel Java se distingue des processeurs "classiques" par le fait qu'il ne comprend aucun registre utilisateur c'est à dire des registres que le programmeur peut utiliser directement (le processeur Java dispose bien évidemment de registres spécialisés pour stocker le PC, Program Counter ou le SP, Stack Pointer). A la place, on utilise des variables locales numérotées à partir de 0. Cette caractéristique peut paraître étonnante au premier abord mais en réalité, elle est tout à fait logique : le bytecode Java devant être exécutable sur plusieurs plates-formes différentes, il n'était pas possible de définir un nombre de registres précis, sans risquer de rencontrer un processeur n'en disposant pas d'autant.

L'absence de registres implique l'utilisation intensive de la pile. En fait, à chaque fois que la JVM charge une classe afin de l'exécuter (nous en reparlerons juste après), elle crée un thread dédié. Chaque thread dispose de sa propre pile, celle-ci n'étant donc pas partagée entre plusieurs instances de classes en cours de traitement. Le processeur fait usage de la pile pour passer des arguments à des fonctions lors de leur appel, comme pour l'exécution d'opérations mathématiques. Le jeu d'instructions comporte donc un certain nombre de commandes permettant de gérer la pile.

La JVM dispose enfin d'instructions natives dédiées à des fonctionnalités spécifiques du langages Java, comme les threads, la création et la manipulation de tableaux et d'objets.

Avant d'aller plus loin, précisons un point. Bien que nous ayons surtout cité l'interpréteur Java livré dans un kit de développement, comme étant la première implémentation d'une machine virtuelle, il en existe en fait une autre, tout aussi importante : le navigateur web. En effet, quand on dit qu'un navigateur est compatible Java, cela veut tout simplement dire qu'il implémente une machine virtuelle Java.

Nous venons en fait de décrire qu'une partie de la JVM, à savoir, le moteur d'exécution (ou Execution Engine), chargé de traduire les bytecodes en instructions exécutables par le processeur de la machine hôte. Bien que ce moteur soit le cœur de la machine virtuelle, celle-ci comporte d'autres éléments comme le chargeur de classes (class loader) et le vérificateur de classes (class verifier), élément clé de la sécurité de la JVM, faisant l'objet d'un paragraphe dédié à la fin de ce chapitre.

La machine virtuelle Java constitue en réalité ce qu'on appelle un runtime Java. Le schéma ci-dessous présente l'architecture d'un runtime Java.

Détaillons chacun des composants présentés dans la figure précédente :

• Moteur d'exécution : Il s'agit du cœur de la machine virtuelle, dont nous avons déjà beaucoup parlé. Ce moteur constitue en fait le processeur virtuel Java, chargé, rappelons-le, de convertir des bytecodes Java en des instructions exécutables par le processeur du système considéré.
• Gestionnaires exceptions/threads/sécurité : Ces gestionnaires sont chargés d'une partie du travail de la JVM. Le gestionnaire d'exceptions permet d'exécuter une portion de code particulière lorsqu'il se produit une erreur durant l'exécution d'un programme (Cf. chapitre IX). Le gestionnaire de threads a pour fonction de permettre l'exécution de plusieurs parties de code simultanément (Cf. chap. VII). Enfin, le gestionnaire de sécurité a un rôle important dans la sécurité de la JVM. Il veille en effet à ce qu'un programme exécuté par le moteur ne vienne pas à remettre en cause l'intégrité du système d'exploitation.
• Gestionnaire mémoire : Cette partie de la JVM gère, comme son nom l'indique, les ressources mémoire. On distingue plusieurs zones (de gauche à droite sur le schéma) : une zone réservée au stockage d'informations sur les structures de données associées aux classes et aux méthodes, une zone dédiée au support des fonctions natives, c'est à dire en fait des fonctions non écrite en bytecode Java mais dans un autre langage, et enfin une zone de mémoire gérée dynamiquement.
  Il est important de préciser à ce niveau de l'exposé qu'en Java, comme nous le verrons le moment venu, on ne désalloue jamais un tableau ou un objet précédemment alloué. Il existe en effet un processus dédié, appelé garbage collector, chargé de récupérer la mémoire qui n'est plus utilisée lors de l'exécution d'un programme. Ce processus n'est pas appliqué aux deux premières zones de mémoire, gérées par le gestionnaire de mémoire, que nous venons de décrire.
• Chargeur de classes dynamique et vérificateur : Un programme Java étant composé de plusieurs classes, le chargeur de classes a pour but de copier en mémoire les classes demandées lors de l'exécution d'un programme (au moment de l'instanciation d'un objet, comme nous le verrons). Ce chargeur peut aussi bien aller chercher une classe livrée avec l'environnement de programmation (API Java) mais aussi aller récupérer une classe via un fichier local ou une connexion par réseau. Ce chargement s'effectuant à la demande, on dit que le chargeur de classes est dynamique.
  Le vérificateur quant à lui a un rôle fondamental : vérifier qu'une classe ne contienne pas de code susceptible de planter la machine virtuelle, voire le système hôte tout entier. Nous verrons au paragraphe suivant comment il fonctionne.

Les composants les plus sensibles de la Machine Virtuelle Java, dont nous venons de découvrir l'architecture interne, sont ceux qui assurent la sécurité de celle-ci (ou plutôt du système d'exploitation hôte). Examinons de plus près le fonctionnement de ces composants.

On peut distinguer plusieurs niveaux de sécurité :

• au niveau du langage, c'est à dire interdire l'accès d'une méthode à une donnée protégée,
• au niveau de la JVM, en éviter de la faire planter en cas d'erreur d'exécution,
• au niveau du système, comme les ressources mémoire,
• au niveau des informations locales, à savoir l'accès au fichiers locaux, en lecture ou écriture.

La sécurité vis à vis d'un programme Java est assurée par plusieurs éléments qui interviennent à différents endroits du "chemin d'évolution" d'un programme, en commençant par son écriture et en terminant par son exécution.

Il est possible de définir trois niveaux de fonctionnalités permettant d'assurer la sécurité.

Le compilateur Java

Première barrière, le compilateur a pour rôle de vérifier qu'un programme Java n'effectue pas des instructions illégales comme tenter d'accéder à une donnée privée d'une autre classe ou essayer de modifier le contenu d'une adresse mémoire (car ce n'est pas autorisé en Java).

Le vérificateur de classes et de bytecodes

C'est pour éviter que des classes générées de cette façon ne provoquent des opérations invalides, que Sun a intégré un vérificateur de classes, exécuté sur toutes les classes chargées non localement par le chargeur de classes, lors de l'exécution d'un programme. Le vérificateur de classes vérifie la structure de celles-ci, puis exécute un vérificateur de bytecode.

Ce vérificateur va plus loin en examinant les bytecodes de façon à vérifier qu'il n'y a pas, par exemple, de sauts à des adresses invalides ou qu'on ne tente pas d'exécuter des opérations avec des types de données incompatibles. L'une des fonctions de ce vérificateur est également de s'assurer qu'un programme ne viendra pas saturer les ressources de la JVM, comme la pile, en exécutant un démonstrateur de théorèmes (theorem prover), visant à détecter d'éventuelles incohérences dans la sturcture des zones de données durant l'exécution répétée (i.e. dans une boucle) d'une même séquence d'instructions.

Dernier rempart, le gestionnaire de sécurité ou Security Manager (SM) a pour but de s'assurer qu'un programme n'accède pas, par exemple, à un fichier local alors qu'il n'en a pas le droit. Le Security Manager peut être redéfini par le programmeur d'une application indépendante d'un navigateur, mais il est impossible de faire une telle redéfinition dans une applet qui, par définition, vient d'une source distante dont l'honnêteté ne peut être assurée. C'est pourquoi une applet ne peut pas accéder au système de fichier local, ou créer un serveur sur la machine hôte.

Cependant, avec l'arrivée des applet signées, il devient possible d'envisager d'élargir les possibilités des applets, grâce à l'utilisation de clés chiffrées identifiant de manière absolue (ou presque) l'origine d'une classe. C'est ce système qui a été adopté par Microsoft pour assurer la sécurité des "applications" ActiveX, comme nous le verrons dans la deuxième partie de cette étude.