Couverture ElectroniqueS n°127

L'emploi du langage Java est appelé à se répandre dans plusieurs secteurs de l'embarqué. Les éditeurs de systèmes d'exploitation et de plates-formes Java s'organisent en conséquence. C'est ainsi que l'on voit se développer une pléthore de spécifications correspondant à chaque domaine d'application. Une plate-forme Java est composée de trois éléments : le langage, la machine virtuelle et les bibliothèques. Le langage est le domaine du programmeur, qui a toujours en tête, aujourd'hui, la promesse lancée par Sun à la création de Java : « write once, run anywhere » ou « écrivez une fois, exécutez partout ». Un compilateur Java crée en effet un « bytecode » ou pseudo-code intermédiaire qui est censé pouvoir s'exécuter sur n'importe quelle cible. Il tournera, en fait, sur toute cible où se trouve une « machine virtuelle » ou JVM (Java virtual machine). Ce logiciel exécutable, qui définit comme son nom l'indique un ordinateur abstrait, accepte la syntaxe des instructions de bytecode et les traduit dans le langage natif de la machine cible. La JVM gère aussi les interactions avec le système d'exploitation local. Sur la cible se trouvent également des bibliothèques de classes(*) dont les programmes Java peuvent avoir besoin pour s'exécuter : la bibliothèque de classes graphiques java.awt, la bibliothèque java.math, la bibliothèque réseau java.net, etc. La JVM comporte un chargeur de classes, et l'écriture de programmes Java consiste principalement à exploiter l'API qui permet d'appeler ces classes ; la vaste gamme de fonctions disponibles facilite singulièrement le travail du concepteur. La mise à jour dynamique du code par téléchargement peut aussi simplifier la mise au point et la maintenance. La cible peut être constituée classiquement par un PC ou une station Unix, mais aussi bien par tout système doté d'un noyau temps réel ou d'un Linux embarqué. Java, qui a démarré sa vie dans le monde des stations, a pourtant été conçu à l'origine pour l'embarqué, et plus exactement pour l'électronique grand public. C'est ainsi que le bytecode est plus compact que certains binaires générés en langage machine, pour la même fonction ! Mais, paradoxalement, une partie seulement des JVM disponibles sur le marché convient à l'embarqué. C'est à ces dernières que ce « Dossier » s'intéresse. Une bonne intégration avec l'OS Toute machine virtuelle a besoin d'un OS ou au moins d'une bibliothèque de fonctions « runtime » pour s'exécuter sur la cible. Les plates-formes embarquées les plus élaborées feront toujours coexister des applications C et Java, et utiliseront un OS généraliste. La figure 4 montre l'architecture du logiciel système (OS, JVM et bibliothèques) d'un calculateur embarqué capable d'exécuter des applications C et Java. Le module JNI (Java native interface) permet d'appeler des routines C depuis l'application Java. Ce qui peut être utile mais induit une perte de portabilité… Toutes les combinaisons de bibliothèques sont possibles ; par exemple, dans l'environnement Linux/Java de MontaVista, qui utilise la JVM J9 d'IBM, il est possible d'utiliser soit la bibliothèque graphique Qte de MontaVista Linux, soit les classes Awt de la JVM. MontaVista a réécrit les couches basses des classes Awt afin de les adapter à l'embarqué, tout en conservant l'API standard côté bytecode Java. Divers modules middleware sont disponibles, dont un client OSGi. Comme on le voit dans le tableau qui suit, la plupart des fournisseurs d'OS enfouis ont une offre Java, souvent en tierce-partie. Wind River, qui offrait sa propre machine PersonalJava, est désormais un OEM d'Insignia avec Jworks, conforme CDC/Foundation. Ose Systems, partenaire de NewMonics pour les applications de réseau, a passé un accord avec IBM pour sa suite « Wireless ». Le portage de la machine Java peut suivre des approches plus ou moins sophistiquées : il se fera soit en cherchant à établir une correspondance entre les threads Java et les tâches de l'OS, soit en confinant l'exécution de la JVM dans un processus de l'OS, dont l'utilisateur peut ajuster la priorité. Quelle que soit l'approche choisie, elle sera plus facile à optimiser dans le cadre d'un partenariat étroit entre l'éditeur de l'OS et celui de la JVM. (*) Voir glossaire page 102. Glossaire CDC : Connected device configuration CLDC : Connected limited device configuration J2ME : Java 2 micro edition J2SE : Java 2 standard edition JCP : Java community process JNI (Java native interface) : permet à un programme Java d'appeler une « méthode native » (routine C ou Java compilée dans le code natif de la machine) JIT : Just in time (compilateur) JVM : Java virtual machine MIDP : Mobile information device profile AOT : Ahead of time (compilateur) Classe : notion de base en programmation objet, il s'agit du modèle générique d'« objets » (composantes modulaires d'un programme) qui ne diffèrent que par la valeur de leurs attributs. En Java, qui est un langage à objets, il n'est possible de créer une application qu'à partir de classes. Objet : instance (exemplaire) de classe créée à partir d'une classe lorsque le programme est lancé, avec ses propres valeurs d'attributs. Tous les objets d'une classe ont en commun leurs « méthodes » (code exécutable des opérations), « attributs » (variables), informations de débogage, propriétés d'héritage et droits d'accès.

Les machines Java pour l’embarqué

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

Les machines Java pour l’embarqué

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure