TR != RT

Il y a de cela quelques semaines, nous avons eu la chance d'avoir la visite de Greg Bollella, Distinguished Engineer (terminologie totalement intraduisible) à Sun Labs, venu chez nous pour parler du projet Mackinac à une grande société française travaillant dans la défense. Plus de 35 personnes étaient présentes, un record pour un vendredi après-midi en plein mois de juillet. Ce projet est basé sur la spécification Real-Time Specification for Java du JSR 1 qui, comme son nom l'indique, fut historiquement le premier à démarrer au sein du Java Community Process en 1999. On pourrait être surpris du temps qu'il aura fallu à ce groupe de travail pour aboutir à une spécification stable dont une démonstration a été faite durant le dernier JavaOne. Pourtant, en écoutant Greg, je me suis rendu compte de l'énorme chantier qu'a représenté l'adaptation de Java au temps-réel (TR). Trois principes ont servis de base pour le JSR 1: supporter les pratiques du monde du TR en matière de programmation et conception d'applications, rester compatible avec les versions officielles de Java en passant les tests du TCK du JSR 1 et de ceux de J2SE, J2ME et J2EE, offrir aux développeurs une couche d'abstraction leur permettant de « penser » leurs applications en termes de contrôle de comportement temporel.

Big deal! On pourrait croire que la montée en puissance des processeurs et de la taille mémoire disponible sont suffisants pour permettre de qualifier un programme de TR sans avoir à ce préoccuper de la logique interne de son fonctionnement (the faster, the better). Ceci est évidemment une erreur que les participants à cette présentation, tous spécialistes du TR, ne faisaient pas. Ils ont donc particulièrement apprécié qu'au travers des API de RTSJ leur soit donné le contrôle du temps par les 28 points d'entrée à priorité variable du scheduler et de la mémoire par les fonctionnalités apportées par les classes ScopeMemory et NoHeapRealTimeThread. Le débat reste ouvert sur les futures évolutions des garbage collector afin que ceux-ci soient capables de prendre en compte le TR, ce qui résoudrait le problème actuel de RTSJ qui oblige le programmeur à se préoccuper à nouveau de la gestion de la mémoire de son application. Prochaine étape en Mars !