Brevet FR3029658A1 — publié le 20160610

SYSTEME ET METHODE DE GESTION DE CODE OCTAL JAVA L'invention a trait à une méthode et un système pour l'analyse et la transformation automatique de code octal (bytecode) Java en code octal Java temps réel. Le code octal ou code à octets, est couramment désigné sous l'anglicisme « bytecode ». Ces différentes dénominations sont utilisées alternativement au définition. Un code code source et intermédiaire, le exécutable par le couramment utilisé cours de ce document et se rattachent à la même octal (bytecode) est un code intermédiaire entre un des instructions machine. En tant que code code octal (bytecode) n'est pas directement processeur d'une ressource matérielle, mais est par les programmateurs car il permet de réduire la dépendance vis-à-vis du matériel et facilite son interprétation sur différentes architectures. Dans le contexte de Java, le bytecode Java se rapporte à un code intermédiaire regroupant des instructions exécutables par une machine virtuelle Java. Le bytecode Java résulte typiquement d'un code produit par une machine virtuelle Java à partir d'un code source, non-nécessairement écrit en langage Java. Le bytecode Java se présente, alors, sous la forme d'un flux d'octets binaires, regroupant des instructions bas-niveau pouvant être exécutées par une machine virtuelle Java, sa bonne exécution étant garante de sa portabilité. On entend, ici, par « code Java temps réel », un code Java contenant des entités définies en accord avec la Spécification Temps Réel pour Java dite RTSJ, acronyme anglais de « Real-Time Specification for Java ». Par opposition, on désigne, ici, sous la dénomination « code Java standard », tout code Java non-temps réel, respectant les conventions établies pour le codage d'applications Java. On entend, en outre, par « déterministe » tout code source, code octal ou application résultante de la compilation ou interprétation du code source, présentant une variation de temps d'exécution minimale. A titre d'exemple, la variation du temps d'exécution d'une application est mesurée par une métrique nommée « jitter », permettant d'évaluer la différence entre le meilleur et le pire temps d'exécution de l'application. Pendant l'exécution d'une application temps réel, il convient de s'assurer que l'ensemble des composantes (ex : méthodes invoquées) 3029658 2 de cette application sont aussi temps réel. Le code source de l'application n'est néanmoins pas toujours disponible ou accessible. Une telle situation survient, à titre d'exemples, lorsque l'on ne dispose que du code binaire d'une application fourni sous forme d'archives 5 Java, lors de l'arrêt de l'édition de l'application ou encore en cas de perte de son code source. Si le code source est accessible, il se peut aussi que la base de code de l'application soit grande ou/et contienne des morceaux de code développés par des équipes externes, rendant toute reconception de l'application, ainsi que son recodage, difficile 10 voire impraticable. Pour les mêmes raisons, la transformation d'un bytecode Java standard vers un bytecode Java temps réel s'en voit fortement limitée. Afin d'adresser ces problèmes, une première solution consiste à repenser l'architecture de l'application, puis la ré-implémenter de 15 manière à obtenir une architecture temps réel. Néanmoins, une telle solution ne peut s'appliquer qu'à des projets simples, c'est-à-dire ne possédants pas un nombre important de classes à modifier, et pour lesquels on dispose de la totalité du code source. Une autre solution consisterait à exécuter, sur une machine virtuelle Java temps réel, 20 c'est-à-dire une machine virtuelle Java en accord avec la spécification RTSJ, l'application originelle. Une telle solution permettrait potentiellement d'augmenter le déterminisme de l'application, grâce aux changements imposés sur la sémantique de plusieurs mécanismes internes, tels les politiques d'ordonnancement et/ou le déclenchement 25 du ramasse-miette (« garbage collector » en anglais). Cependant, l'application ne bénéficierait alors que peu de mécanismes temps réels définis dans la spécification RTSJ. Une autre solution consiste à utiliser une programmation orientée aspect. Une telle technique permet de s'affranchir du langage de programmation utilisé et de définir des points 30 de coupure permettant l'adaptation de classes Java. Avantageusement, les points de coupure définissent des endroits spécifiques où des morceaux de code peuvent être insérés. Il est, ainsi, possible de séparer différentes préoccupations, par exemples de type transversales et/ou métiers, représentées par des aspects. L'utilisation d'aspects 35 permet ainsi de spécifier et discriminer, à titre d'exemples, des classes ou des librairies, où des modifications doivent être apportées. Ces modifications s'effectuent alors par l'inclusion de code au niveau des 3029658 3 points de coupure spécifiés, et sont réalisées de manière statique ou dynamique via un tisseur d'aspects ou de canevas apte à manipuler le bytecode. Une telle solution nécessite, cependant, la réalisation de davantage de code pour spécifier les modifications. De plus, l'utilisation 5 d'aspects se limite à la modification du code et ne permet pas l'analyse de ce dernier, par exemple l'analyse de sa qualité. L'invention proposée a pour but de répondre à l'ensemble des inconvénients précités. Un premier objectif est de proposer un outil permettant l'analyse et 10 la transformation de bytecode Java en bytecode Java temps réel. Un deuxième objectif est de proposer un outil permettant d'analyser la qualité d'un bytecode Java. Un troisième objectif est de proposer un outil garant des performances de toute application, de sorte que toute modification de 15 bytecode Java n'affecte pas le temps d'exécution de l'application. Un quatrième objectif est de proposer un outil garant de la consistance de toute application, de sorte que toute modification de bytecode Java ne corrompe pas le fonctionnement des classes modifiées. 20 Un cinquième objectif est de proposer un outil présentant une architecture souple, extensible et réutilisable en vue d'anticiper de futures évolutions techniques. Un sixième objectif est de proposer un outil configurable par l'utilisateur. 25 A cet effet, il est proposé, selon un premier aspect, un système de gestion de code octal Java, permettant la transformation de code octal Java en code octal Java temps réel, ce système comprenant des modules configurés pour réceptionner en entrée un code octal Java ; 30 - réceptionner un fichier de configuration, ce fichier de configuration spécifiant o au moins un élément du code octal Java à substituer par un élément de code octal Java temps réel ; o au moins une règle de traitement concernant cet élément, cette 35 règle décrivant au moins un paramètre pour effectuer la substitution de l'élément du code octal vers l'élément de code octal Java temps réel ; 3029658 4 lire le fichier de configuration reçu et extraire du fichier de configuration ladite règle de traitement à appliquer sur l'élément spécifié du code octal Java reçu ; appliquer ladite règle de traitement extraite à l'élément de code 5 octal Java permettant d'obtenir un code octal Java temps réel ; fournir en sortie le code octal Java temps réel obtenu. Avantageusement, ce système comprend un module d'analyse et de modification statique et un module d'analyse et de modification dynamique, ces modules étant respectivement configurés pour 10 réceptionner le code octal Java - avant son chargement en mémoire et avant son exécution ; - pendant son chargement en mémoire et avant son exécution ; ces modules étant, en outre, configurés pour réceptionner le fichier de configuration ; 15 - analyser le code octal Java réceptionné et/ou transformer ce code octal vers un code octal Java temps réel en fonction du fichier de configuration. Avantageusement, dans ce système, le module d'analyse et de modification statique, et le module d'analyse et de modification 20 dynamique comprennent un mécanisme d'analyse et de transformation, le mécanisme d'analyse et de transformation étant réalisé par au moins un module d'analyse et de transformation, chaque module d'analyse et de transformation comprenant une méthode de traitement de fichier, apte à lire le fichier de 25 configuration et en extraire des informations comprenant ladite règle de traitement, le fichier de configuration étant fourni comme entrée de ce module ; une ou plusieurs méthodes de traitement de code octal Java, aptes à appliquer une analyse et/ou une modification sur au moins un 30 élément d'un code octal Java fourni en entrée de ce module, en fonction des informations extraites du fichier de configuration. Avantageusement, dans ce système, le code octal Java réceptionné par le module d'analyse et de modification statique, comprend pour élément(s) une ou plusieurs 35 classes Java dans au moins une archive Java dite fichier JAR ; 3029658 5 le code octal Java réceptionné par le module d'analyse et de modification dynamique, comprend pour élément(s) une ou plusieurs classes Java directement accessibles ; le module d'analyse et de modification statique et le module 5 d'analyse et de modification dynamique sont configurés pour transmettre le code octal Java et le fichier de configuration réceptionnés au mécanisme d'analyse et de transformation ; le mécanisme d'analyse et de transformation est configuré pour transmettre le fichier de configuration à chaque module d'analyse 10 et de transformation ; chaque module d'analyse et de transformation est configuré pour lire via sa méthode de traitement de fichier, le fichier de configuration et extraire en fonction de cette lecture une ou plusieurs règles de traitement à appliquer à une ou plusieurs 15 classes du code octal Java. Avantageusement, dans ce système, le mécanisme d'analyse et de transformation est configuré pour enregistrer en tant qu'entrée dans une table, chaque règle de traitement extraite par chaque module d'analyse et de 20 transformation ; comparer chaque classe du code octal Java réceptionné avec chaque règle de traitement enregistrée dans la table ; identifier par association entre une classe du code octal Java et une entrée de la table, un ou plusieurs module d'analyse et de 25 transformation aptes à traiter cette classe ; si au moins un module d'analyse et de transformation est identifié et o si le code octal Java est réceptionné par le module d'analyse et de modification statique, extraire le code octal Java de chaque 30 fichier JAR et le transmettre au(x) module(s) d'analyse et de transformation identifié(s) pour transformer une ou plusieurs de ses classes en classes Java temps réel et obtenir un code octal Java temps réel ; o si le code octal Java est réceptionné par le module d'analyse et 35 de modification dynamique, transmettre le code octal Java au(x) module(s) d'analyse et de transformation identifié(s) pour 3029658 6 transformer une ou plusieurs de ses classes en classes Java temps réel et obtenir un code octal Java temps réel ; après la transformation d'une ou plusieurs classes du code octal Java par l'ensemble des modules identifiés 5 o sauvegarder le code octal Java temps réel dans un nouveau fichier JAR en remplacement respectif de chaque fichier JAR, si le code octal Java est réceptionné par le module d'analyse et de modification statique ; o envoyer le code octal Java temps réel vers le chargeur de classe 10 d'une machine virtuelle Java, si le code octal Java est réceptionné par le module d'analyse et de modification dynamique. Il est proposé, selon un deuxième aspect, une méthode de gestion de code octal Java, permettant la transformation de code octal Java en 15 code octal Java temps réel, cette méthode comprenant une étape de réception d'un code octal Java ; une étape de réception d'un fichier de configuration, ce fichier de configuration spécifiant o au moins un élément du code octal Java à substituer par un 20 élément de code octal Java temps réel ; o au moins une règle de traitement concernant cet élément, cette règle décrivant au moins un paramètre pour effectuer la substitution de l'élément du code octal vers l'élément de code octal Java temps réel ; 25 - une étape de lecture du fichier de configuration reçu ; une étape d'extraction du fichier de configuration de ladite règle de traitement à appliquer sur l'élément spécifié du code octal Java reçu ; une étape d'application de ladite règle de traitement extraite à 30 l'élément de code octal Java permettant d'obtenir un code octal Java temps réel ; une étape de fourniture du code octal Java temps réel obtenu. Avantageusement, dans cette méthode, le code octal Java est réceptionné 3029658 7 o avant son chargement en mémoire et avant son exécution, et comprend pour élément(s) une ou plusieurs classes Java dans au moins une archive Java dite fichier JAR ; o ou pendant son chargement en mémoire et avant son exécution, 5 et comprend pour élément(s) une ou plusieurs classes Java directement accessibles ; ledit au moins un élément du code octal Java à substituer est une classe Java ; ladite au moins une règle de traitement concernant cet élément est 10 enregistrée dans une table. Avantageusement, dans cette méthode, la transformation de code octal Java en code octal Java temps réel ainsi que sa fourniture sont réalisées par l'extraction du code octal de chaque fichier JAR si le code octal 15 Java est réceptionné avant son chargement en mémoire et avant son exécution ; l'application de ladite règle de traitement audit au moins un élément du code octal Java ; si le code octal Java est réceptionné avant son chargement en 20 mémoire et avant son exécution, la création respective pour chaque fichier JAR extrait d'un nouveau fichier JAR comprenant l'ensemble du code octal Java temps réel ; sinon, l'envoi des classes du code octal Java temps réel vers le chargeur de classe d'une machine virtuelle Java. 25 Il est proposé, selon un troisième aspect, un produit programme d'ordinateur implémenté sur un support mémoire, susceptible d'être mis en oeuvre au sein d'une unité de traitement informatique et comprenant des instructions pour la mise en oeuvre de la méthode résumée ci-dessus. 30 D'autres objets et avantages de l'invention apparaîtront à la lumière de la description d'un mode de réalisation, faite ci-après en référence au dessin annexé, dans lequel la figure 1 illustre l'architecture logique d'un système d'analyse et de modification de code octal Java selon un mode de réalisation. 35 Sur la figure 1 est représenté sur un diagramme de classes en Langage de modélisation unifié dit UML (acronyme anglais de « Unified 3029658 8 Modeling Language ») 2.0, l'architecture logique d'un système 100 de gestion de code octal Java, permettant de manière configurable l'analyse de code octal Java standard, et/ou la transformation de ce code vers un code Java temps réel selon un mode de réalisation. 5 Sur cette figure, le système 100 de gestion de code octal Java comprend - un module d'analyse et de modification statique 1, implémenté et représenté ici sous forme de classe, configuré pour analyser un code octal Java standard d'une application, et/ou transformer ce 10 code octal vers un code octal Java temps réel, avant le chargement en mémoire et l'exécution de ce code octal ; un module 2 d'analyse et de modification dynamique, implémenté et représenté ici sous forme de classe, configuré pour analyser un code octal Java standard d'une application, et/ou transformer ce 15 code octal vers un code octal Java temps réel, pendant le chargement de ce code octal en mémoire. Le chargement d'un bytecode (code octal) Java en mémoire est réalisé, à titres d'exemples, via un chargeur de classes d'une machine virtuelle Java, apte à 20 charger en mémoire les classes constitutives du code octal ; un mécanisme d'agents Java prévu dans la spécification Java, ces agents étant configurés de manière à être appelés pour le chargement du code octal Java. Dans une mode de réalisation, la fourniture du bytecode d'une 25 application au module d'analyse et de modification statique 1 et/ou du module d'analyse et de modification dynamique 2 est réalisée via un agent Java. Un tel agent est, à titre d'exemple, une classe spéciale liée à une machine virtuelle Java, dont les méthodes sont appelées lors du chargement en mémoire de chaque classe de bytecode, ces méthodes 30 permettant l'interception des classes de bytecode. Avantageusement, le module 1 d'analyse et de modification statique et le module 2 d'analyse et de modification dynamique partagent de manière commune un mécanisme 3 d'analyse et de transformation. Le mécanisme 3 d'analyse et de transformation est 35 implémenté et représenté ici sous la forme d'une classe qui est une instance du module 1 d'analyse et de modification statique et du 3029658 9 module 2 d'analyse et de modification dynamique. Les losanges blancs 101, 102 entre ces différents modules illustrent sur cette figure, leur relation d'agrégation conformément à la modélisation UML 2.0. Avantageusement, le mécanisme d'analyse et de transformation 3 est 5 composé d'au moins un module 4 d'analyse et de transformation, implémenté et représenté ici sous la forme d'une classe qui est une instance du mécanisme d'analyse et de transformation 3. Cette relation est symbolisée par le losange blanc 103 entre ces deux classes, illustrant leur relation d'agrégation, conformément à la modélisation 10 UML 2.0. Avantageusement, le module 4 d'analyse et de transformation implémente une pluralité de méthodes, et comprend au moins les méthodes suivantes : une méthode de traitement de fichier, apte à lire un fichier 5 de 15 configuration qui est fourni en entrée de ce module. Une telle méthode utilise, à titre d'exemple, une bibliothèque spécifique apte à charger et analyser la syntaxe (c'est-à-dire « parser ») d'un fichier 5 de configuration selon un format prédéfini, par exemple au format XML ; 20 - une ou plusieurs méthodes de traitement de bytecode, apte à appliquer une analyse et/ou une modification sur un bytecode fourni en entrée du module en fonction du fichier de configuration 5 qui est fourni en entrée de ce module. Avantageusement, le fichier 5 de configuration est paramétré par 25 l'utilisateur et fourni en entrée du système 100 de gestion de code octal Java. Le fichier 5 de configuration permet à l'utilisateur de spécifier les différentes analyses et/ou transformations à effectuer sur le bytecode Java standard d'une application. Plus précisément, le fichier 5 de configuration permet à l'utilisateur de lister un ensemble ou un sous- 30 ensemble d'éléments constitutifs d'un bytecode Java standard (ex : classes, bibliothèques, méthodes, autres ressources), destinés à être substitués par des éléments de même type et remplissant les mêmes fonctions en accord avec la spécification Java temps réel RTSJ, permettant donc l'obtention d'un bytecode Java temps réel. A titre 35 d'exemple, un tel fichier est structuré de manière à lister 3029658 10 un ensemble de classes et/ou de méthodes constitutives d'une application, devant être modifiées en vue d'obtenir un bytecode Java temps réel déterministe ; les propriétés/paramètres des futures nouvelles classes et/ou 5 méthodes (ex : attributs, fréquences d'exécution, priorités) Java temps réel se substituant aux classes et/ou méthodes Java standard ; un ou plusieurs chemins de fichiers, ou une expression désignant un ensemble de fichiers, à inspecter en utilisant des patrons pour 10 l'inclusion et/ou l'exclusion de fichiers UNIX ou DOS. En fonction de l'état d'exécution de l'application, le fichier 5 de configuration est communiqué au module 1 d'analyse et de modification statique avant tout chargement en mémoire et exécution du bytecode (flèche pointillée 15 104) ; au module 2 d'analyse et de modification dynamique, pendant le chargement du bytecode en mémoire et avant toute exécution de ce bytecode (flèche pointillée 105). Ce fichier est alors transmis par un de ces modules au mécanisme 20 3 d'analyse et de transformation, qui le communique à son module 4 d'analyse et de transformation, ce dernier applique alors les analyses et/ou transformations spécifiées dans le fichier au bytecode Java standard de l'application. Dans un mode de réalisation, le mécanisme 3 d'analyse et de 25 transformation est multi-modulaire, c'est-à-dire est réalisé par l'agrégation d'une pluralité de modules 4 d'analyse et de transformation, chacun comprenant des méthodes d'analyse et de traitement de bytecode spécifiques. Avantageusement, l'aspect modulaire permet de rajouter un module 4 d'analyse et de 30 transformation comportant une méthode d'analyse et/ou de transformation de bytecode spécifique en réponse à un besoin particulier, permettant ainsi de proposer un système évolutif, configurable et facilement extensible. Selon divers modes de réalisation, il est possible pour un 35 utilisateur du système 100 de gestion de code octal Java, de sélectionner l'activation ou la désactivation d'un ou plusieurs modules 4 3029658 11 d'analyse et de transformation spécifiques. Une telle sélection peut, à titre d'exemples, être indiquée dans le fichier 5 de configuration fourni par l'utilisateur au système 100 de gestion de code octal Java ; 5 indiquée par un ou plusieurs paramètres de ligne(s) de commandes saisies par l'utilisateur dans un terminal de commande apte à exécuter l'application ; injectée par un canevas tiers, par exemple via une approche orientée service ; 10 instanciée directement dans le code de l'application. Si le bytecode Java standard n'a pas encore été chargé en mémoire, les classes et autres ressources implémentées par celui-ci sont alors regroupées dans une ou plusieurs archives Java dites fichiers JAR 6 (acronyme anglais de « Java ARchive »), trois dans 15 l'exemple illustré sur la figure 1. Sur cette figure, chaque fichier JAR 6 comprend trois classes originales de bytecode 7, c'est-à-dire des classes de bytecode non-modifiées, et éventuellement d'autres ressources 8 (ex : fichier(s) texte, image(s)). Le système 100 de gestion de code octal Java effectue alors les 20 opérations suivantes : le module 1 d'analyse et de modification statique prend pour entrée chaque fichier JAR 6 (flèche pointillée 106) ainsi que le fichier 5 de configuration (flèche pointillée 104), et les transmet au mécanisme 3 d'analyse et de transformation ; 25 - le mécanisme 3 d'analyse et de transformation communique ensuite à l'ensemble des modules 4 d'analyse et de transformation le fichier 5 de configuration ; chaque module 4 d'analyse et de transformation applique ensuite sa méthode de traitement de fichier, afin de lire le fichier 5 de 30 configuration et déterminer d'éventuels éléments du bytecode, dans cet exemple des classes originales de bytecode 7, à analyser et/ou à modifier. Chaque module 4 d'analyse et de transformation génère alors en fonction la lecture du fichier 5 de configuration, une liste de règles à appliquer au bytecode, par exemple effectuer 35 une analyse ou une substitution sur des classes et/ou méthodes spécifiques. L'ensemble de ces règles sont, à titre d'exemple, 3029658 12 communiquées par chaque module 4 d'analyse et de transformation au mécanisme 3 de transformation qui les enregistre dans une table associative, comprenant pour chacune de ses entrées l'identifiant d'un module 4 d'analyse et de transformation et 5 l'ensemble des règles qui lui sont associées. Cet exemple est développé par la suite. Dans un autre exemple, chaque module enregistre ses propres règles le concernant, puis compare par la suite chaque classe du bytecode avec ses propres règles afin d'identifier d'éventuelles modifications et/ou analyses à conduire 10 sur des classes spécifiques ; le mécanisme 3 d'analyse et de transformation inspecte ensuite les classes de bytecode dans chaque fichier JAR 6, et compare celles-ci avec les entrées de la table associative, en vue d'identifier d'éventuels modules 4 d'analyse et de transformation aptes à 15 traiter ces classes, c'est-à-dire les analyser et/ou modifier ; si une ou plusieurs classes d'un fichier JAR 6 sont listées dans la table associative, le mécanisme 3 d'analyse et de transformation identifie par association le(s) module(s) 4 d'analyse et de transformation apte(s) à traiter ces classes, extrait l'ensemble des 20 octets du bytecode du fichier JAR 6 et transmet l'ensemble du bytecode extrait audit(s) module(s) identifié(s) ainsi que les règles de configuration concernant sont traitement ; chaque module 4 d'analyse et de transformation identifié applique alors à tour de rôle les analyses et/ou modifications spécifiées par 25 le fichier 5 de configuration au bytecode extrait. Plus précisément, le bytecode fourni en entrée d'un module 4 d'analyse et de transformation est analysé et/ou modifié par ledit module, communiqué en l'état en sortie de ce module, puis utilisé comme entrée par le module 4 d'analyse et de transformation suivant ; 30 - lorsque le bytecode a été traité par l'ensemble des modules 4 d'analyse et de transformation identifiés, le mécanisme 3 d'analyse et de transformation reconstruit et fournit en sortie (flèche pointillée 107) du système 100 de gestion de code octal Java, pour chaque fichier JAR 6 extrait, un nouveau fichier JAR 9 comprenant 35 l'ensemble des classes du bytecode Java analysé et/ou modifié. A titre d'exemple, sur la figure 1, le système 100 de gestion de code 3029658 13 octal Java fournit en sortie (flèche pointillée 107) un ensemble de trois nouveaux fichiers JAR 9 comprenant chacun les ressources 8, une classe originale de bytecode 7, c'est-à-dire une classe de bytecode non-modifiée par le mécanisme d'analyse et de 5 transformation 3, et deux classes modifiées de bytecode 10. Dans le cas dynamique, pendant le chargement des classes du bytecode en mémoire (flèche 108) et avant toute exécution du bytecode, les classes originales de bytecode 7 sont directement accessibles une par une. Le système 100 de gestion de code octal 10 Java effectue alors les opérations suivantes : le module 2 d'analyse et de modification dynamique prend pour entrée chaque classe originale de bytecode 7 (flèche pointillée 109) ainsi que le fichier 5 de configuration (flèche pointillée 105), et les transmet au mécanisme d'analyse et de transformation 3 ; 15 - le mécanisme 3 d'analyse et de transformation communique ensuite à l'ensemble des modules 4 d'analyse et de transformation le fichier 5 de configuration ; chaque module 4 d'analyse et de transformation applique ensuite sa méthode de traitement de fichier, afin de lire le fichier 5 de 20 configuration et déterminer d'éventuelles classes originales de bytecode 7 à analyser et/ou modifier. Chaque module 4 d'analyse et de transformation génère alors en fonction la lecture du fichier 5 de configuration, une liste de règles à appliquer au bytecode, par exemple effectuer une analyse ou une substitution sur des classes 25 spécifiques. L'ensemble de ces règles sont, à titre d'exemple, communiquées par chaque module 4 d'analyse et de transformation au mécanisme 3 de transformation qui les enregistre dans une table associative, comprenant pour chacune de ses entrées l'identifiant d'un module 4 d'analyse et de transformation et 30 l'ensemble des règles qui lui sont associées. Cet exemple est développé par la suite. Dans un autre exemple, chaque module enregistre ses propres règles le concernant, puis compare par la suite chaque classe du bytecode avec ses propres règles afin d'identifier d'éventuelles modifications et/ou analyses à conduire 35 sur des classes spécifiques ; 3029658 14 le mécanisme d'analyse et de transformation 3 inspecte ensuite successivement chaque classe originale de bytecode 7, et compare chacune d'elles avec les entrées de la table associative, en vue d'identifier d'éventuels modules 4 d'analyse et de transformation 5 aptes à traiter ces classes, c'est-à-dire les analyser et/ou les modifier ; si une classe originale de bytecode 7 est listée dans la table associative, le mécanisme 3 d'analyse et de transformation identifie par association le(s) module(s) 4 d'analyse et de 10 transformation apte(s) à traiter cette classe, puis la transmet audit(s) module(s) identifié(s) ainsi que les règles de configuration concernant sont traitement ; chaque module 4 d'analyse et de transformation identifié applique alors à tour de rôle les analyses et/ou modifications spécifiées par 15 le fichier 5 de configuration à la classe communiquée. Plus précisément, la classe fournie en entrée d'un module 4 d'analyse et de transformation est analysée et/ou modifiée par ledit module, puis communiquée en l'état en sortie de ce module, puis utilisée comme entrée par le module 4 d'analyse et de transformation 20 suivant ; lorsque qu'une classe de bytecode Java a été traitée par l'ensemble des modules 4 d'analyse et de transformation identifiés, le système 100 de gestion de code octal Java fournit en sortie (flèche pointillée 110) la version modifiée de la classe. Cette 25 classe est ensuite, à titre d'exemple, chargée en mémoire pour exécution par le chargeur de classe d'une machine virtuelle Java. Si aucune analyse et/ou modification n'est effectuée, la classe originale de bytecode 7 est envoyée directement par le système 100 de gestion de code octal Java pour exécution, dans cet 30 exemple, au chargeur de classe de la machine virtuelle Java. Chaque classe, originale ou modifiée, est alors chargée une à une par le chargeur de classe (flèche pointillée 111). A titre d'exemple, sur la figure 1, le système 100 de gestion de code octal Java prend pour entrée (flèche pointillée 109) trois classes originales de 35 bytecode 7 et fournit en sortie (flèche pointillée 110), une classe originale de bytecode 7 et deux classes modifiées de bytecode 10 3029658 15 qui sont successivement chargées par le chargeur de la machine virtuelle Java. Selon divers modes de réalisation, le mécanisme 3 d'analyse et de transformation partagé entre le module 1 d'analyse et de modification 5 statique et le module 2 d'analyse et de modification dynamique, comprend une pluralité de modules 4 d'analyse et de transformation, réalisés par exemple sous forme d'instances, ces modules étant itérés dans deux situations : - lors du traitement du fichier 5 de configuration pour déterminer la 10 liste des classes à traiter (modifier et/ou analyser) ; lors du traitement (analyse et/ou modification) du bytecode de chaque classe. Dans ces modes de réalisation et à titre d'exemples : le fichier 5 de configuration est défini en langage de balisage 15 extensible XML, acronyme anglais de « Extensible Markup Language » ; l'implémentation du système 100 de gestion de code octal Java fait appel à la bibliothèque de classes définies par la spécification RTSJ ; 20 - la bibliothèque Java ASM est utilisée pour la manipulation de bytecode Java. Une telle bibliothèque permet, à titre d'exemple, de générer à partir de classes de bytecode standard, de nouvelles classes en accord avec spécifications temps réelles du standard RTSJ, les propriétés (ex : priorités, fréquence d'exécution) de ces 25 nouvelles classes étant définies dans le fichier de configuration 5 ; la bibliothèque temps réel Javolution est utilisée pour la lecture des fichiers XML (notamment du fichier 5 de configuration), et des structures de données constitutives des classes (ex : listes, ensembles, tableaux associatifs). 30 Selon divers modes de réalisation, en accord avec ces bibliothèques, ou toutes autres bibliothèques présentant des fonctionnalités équivalentes, on réalise les modules 4 d'analyse et de transformation suivants : un module de substitution de classes et d'appels de méthodes. 35 Avantageusement, ce module est configuré pour remplacer dans le bytecode les occurrences d'une classe ou d'une méthode 3029658 16 spécifique, spécifiée dans le fichier 5 de configuration, par une autre classe ou méthode spécifique. A titre d'exemple, un tel module permet de substituer toutes les instanciations d'une liste de type « ArrayList » en Java par des instanciations d'objets 5 « FastList », de la bibliothèque Javolution, permettant ainsi d'augmenter le déterminisme de l'application cible. Avantageusement, les transformations opérées par ce module maintiennent la propriété de consistance du bytecode : on veille à ce que les méthodes et les classes substituées restent 10 compatibles, en présentant respectivement les mêmes signatures (nom, arguments, type de données retournées) et en faisant appel aux mêmes méthodes. La configuration de ce module est réalisée grâce au fichier 5 de configuration dans lequel on ajoute les éléments suivants : 15 o élément de modification « change » : cet élément possède des attributs source « from » (de) et de destination « to » (vers), où l'on peut définir les noms complets des classes à remplacer (« from») et de remplacement (« to»). Pour désigner une méthode, on indique le nom complet de la classe, suivi d'un 20 point, du nom de la méthode, ainsi que de sa signature conformément à la spécification bytecode. A titre exemple, une méthode appelée « executer », sans valeur de retour, et de type virtuelle, désignée sous la signature « V », d'une classe nommée foo.Bar, est désignée par l'expression « foo.Bar.executerOV » ; 25 o élément cible « target » : cet élément est un sous-élément de l'élément de modification « change », et désigne les classes et méthodes dans lesquelles les modifications doivent être exécutées. Deux symboles spéciaux peuvent être utilisés : « * », pour indiquer toutes les classes ou toutes les classes dans un 30 package spécifique ciblées, et « ! » pour exclure des classes, des packages, ou des méthodes ; un module de transformation de fils d'exécutions, désignés par la suite sous l'anglicisme courant « thread ». Avantageusement, ce module est configuré pour remplacer dans le bytecode des threads 35 non-temps réels du type « java.lang.Thread » par des threads temps réel tels que définis dans la spécification RTSJ, par exemple des threads « javax.realtime.RealtimeThread ». Avantageusement, 3029658 17 l'utilisateur peut via le fichier 5 de configuration, affecter des priorités temps réel à ces threads, une échéance (« deadline »), ainsi qu'une date de lancement (« release »). L'utilisation du module de transformation de threads nécessite une connaissance 5 préalable par l'utilisateur du fonctionnement de l'application cible, étant donné que la politique d'ordonnancement des threads dans une machine virtuelle temps réel ne permet pas la préemption d'un thread de priorité plus basse par un thread de priorité plus élevée. Avantageusement, la configuration de ce module est réalisée grâce 10 au fichier 5 de configuration dans lequel on ajoute les éléments suivants : o élément fil d'exécution « thread » : cet élément possède des attributs de priorité « priority », pour définir la priorité du thread, de date de lancement « release », pour définir la date de 15 lancement du thread, et d'échéance « deadline », pour définir l'échéance du thread ; o élément cible « target » : par analogie avec l'élément cible « target » du module de substitution de classes et d'appels de méthodes, cet élément est un sous-élément de l'élément « thread 20 » et permet la désignation des threads et corps de méthodes où le(s) remplacement(s) est (sont) effectué(s). L'utilisation des caractères « *» et « ! » est aussi autorisée ; module de modification de contexte d'allocation de mémoire. Avantageusement, ce module est configuré pour remplacer le 25 contexte d'allocation de mémoire d'une méthode dans le bytecode. Le contexte d'allocation mémoire proposé par ce module utilise le package « javolution.context » de la bibliothèque Javolution, permettant l'utilisation de zones mémoires autres que le tas (« heap » en anglais) et qui ne sont pas impactées par le ramasse- 30 miettes. Ce dernier peut, en effet, introduire de l'indéterminisme dans les données allouées sur le tas. Avantageusement, les threads temps réels obtenus sont réalisés dans des espaces mémoire clairement spécifiés, garantissant ainsi l'isolation leur isolation spatiale au cours de leur exécution. Pour ce faire, le 35 module est configuré pour ajouter un appel pour entrer dans un nouveau contexte mémoire au début de l'exécution d'une méthode, et un autre appel pour sortir de ce contexte mémoire à la fin 3029658 18 d'exécution de ladite méthode. Avantageusement, un tel module est applicable aussi bien aux méthodes ne retournant pas de valeurs (c'est à dire de type « void »), qu'aux méthodes retournant des valeurs. Dans ce dernier cas, on exporte des copies des objets 5 instanciés dans le nouveau contexte mémoire ouvert. Avantageusement, deux types de contextes mémoire sont utilisés : « stack » et « immortal », se rapportant respectivement aux zones mémoires de type étendue (« scoped ») et immortelle (« immortal ») définies dans la spécification RTSJ. L'utilisation de 10 ces deux types d e contextes mémoire, en accord avec la spécification RTSJ, présente en effet plusieurs avantages : la mémoire immortelle (« immortal »), zone de mémoire unique, n'est jamais impactée par le ramasse-miette, tandis que la mémoire de type étendue (« scoped »), zone(s) de mémoire non-allouée(s) sur 15 le tas, présente des possibilités configurables d'appel(s) au ramasse-miette. Il est, en outre, possible pour une application, de définir autant de contextes mémoire de type étendue (« scoped ») que l'on souhaite, et de les partager entre plusieurs threads. La configuration de ce module est réalisée grâce au fichier de 20 configuration 5 dans lequel on ajoute les éléments suivants : o éléments pile mémoire « stackmemory » et mémoire immortelle « immortalmemory » : ces éléments permettent respectivement de définir des contextes mémoire du type « scope » et « immortal », aux méthodes définies dans le sous-élément « target ». Lorsque 25 qu'un nom de classe est défini, la transformation s'applique à toutes les méthodes de cette classe ; o élément cible « target » : par analogie avec les éléments cibles « target » des modules précédemment décrits, cet élément est un sous-élément des éléments pile mémoire « stackmemory » et 30 mémoire immortelle « immortalmemory », permettant la définition (ou l'exclusion) des contextes mémoire et corps de méthodes où la(les) modification(s) est (sont) effectuée(s) ; module de transformation d'historique d'événement (« logging »). Avantageusement, ce module est configuré pour supprimer du 35 bytecode toute référence vers la bibliothèque d'historique d'événements standard de Java (package « java.util.logging »). Cette bibliothèque, couramment réalisée par le fournisseur d'une 3029658 19 machine virtuelle Java, peut en effet introduire des inter-blocages (« deadlocks ») et manque de flexibilité. La configuration de ce module est réalisée grâce au fichier 5 de configuration dans lequel on ajoute les éléments suivants : 5 o élément « logging » : cet élément permet de spécifier la suppression d'une ou plusieurs références vers une bibliothèque d'historique d'événements, et optionnellement leurs remplacement par des références vers une autre bibliothèque spécifique plus performante en terme de déterminisme, et en 10 accord avec le standard RTSJ ; o élément cible « target » : par analogie avec les éléments cibles « target » des modules précédemment décrits, cet élément est un sous-élément de l'élément « logging », permettant la définition (ou l'exclusion) des références et corps de méthodes où la(les) 15 transformation(s) est (sont) effectuée(s) ; module de suppression d'invocations du ramasse-miettes. Avantageusement, ce module est configuré pour supprimer dans le bytecode tout appel explicite au ramasse-miettes (appels via la fonction Java « System.gc( »). Ces appels peuvent, en effet, 20 introduire de l'indéterminisme dans le temps d'exécution de l'application, étant donné que le temps d'exécution de ces appels n'est pas borné. La configuration de ce module est réalisée grâce au fichier de configuration 5 dans lequel on ajoute les éléments suivants : 25 o élément « gc-call » : cet élément permet à l'utilisateur de spécifier la suppression éventuelle de l'invocation explicite du ramasse-miette ; o élément cible « target » : par analogie avec les éléments cibles « target » des modules précédemment décrits, cet élément est un 30 sous-élément de l'élément « gc-call », pour la définition (ou l'exclusion) des invocations du ramasse-miette et corps de méthode où la(les) modification(s) est (sont) effectuée(s) ; module de transformation de méthodes de synchronisation. Avantageusement, ce module est configuré pour remplacer des 35 appels aux méthodes synchronisation d'objets Java et qui peuvent introduire de l'indéterminisme au niveau du temps d'exécution de l'application cible, par exemples des méthodes de type « wait », 3029658 20 « notify » et « notifyAll », par un mécanisme d'événements asynchrones prévu dans la spécification RTSJ. Pour ce faire, un objet temps réel « AsynchronouslyInterruptedException » est ajouté pour chaque membre de classe. Ce module remplace alors 5 les appels de la méthode « notify » sur un objet, par des appels à la méthode « AsynchronouslyInterruptedException.fire0 » sur l'objet correspondant créé. Les appels « wait » peuvent être remplacés par des appels à une méthode spéciale dans une classe implémentant l'interface « Interruptible ». Une telle interface 10 (« javax.realtime.Interruptible ») est utilisée pour définir des objets dont les méthodes peuvent être interrompues au cours de leurs exécutions, lors de l'occurrence d'une exception d'interruption asynchrone « AsynchronousInterruptedException ». Le corps de la méthode spéciale est, par exemple, réalisé par des appels à la 15 méthode « sleep0 ». La configuration de ce module est réalisée grâce au fichier 5 de configuration dans lequel on ajoute les éléments suivants : o élément « event » : cet élément permet à l'utilisateur de spécifier le remplacement des appels aux méthodes de synchronisation 20 d'objets Java ; o élément cible « target » : par analogie avec les éléments cibles « target » des modules précédemment décrits, cet élément est un sous-élément de l'élément « event », pour la définition (ou l'exclusion) des appels aux méthodes de synchronisation d'objets 25 Java et corps de méthodes où le(s) remplacement(s) est (sont) effectué(s) ; module d'analyse des mécanismes de communication. Avantageusement, ce module est configuré pour identifier et supprimer des références aux bibliothèques de traitement 30 d'entrées/sorties (I/O, acronyme anglais de « Input /Output ») et de gestions de connecteurs réseau (« sockets »). En effet, l'utilisation de ces bibliothèques peut compromettre le déterminisme du temps d'exécution des applications temps réel en Java. La configuration de ce module est réalisée grâce au fichier de configuration 5 dans 35 lequel on ajoute les éléments suivants : o élément « systemcomm » : cet élément permet à l'utilisateur de spécifier la suppression de références aux bibliothèques de 3029658 21 traitement d'entrées/sorties et de gestion de connecteurs réseaux. Optionnellement, cet élément permet de spécifier le remplacement de ces références par des appels à des bibliothèques plus performantes et plus déterministes en termes 5 de temps de réponse, par exemple des bibliothèques « ZeroMQ » et/ou « Apache ActiveMQ » ; o élément cible « target » : par analogie avec les éléments cibles « target » des modules précédemment décrits, cet élément est un sous-élément de l'élément «systemcomm » permettant la 10 définition (ou l'exclusion) des références aux bibliothèques de traitement d'entrées/sorties, des références aux bibliothèques de gestion de connecteurs réseaux, et des corps de méthode où la(les) modification(s) est (sont) effectuée(s) ; module d'analyse de complexité. Avantageusement, ce module est 15 configuré pour analyser la complexité d'une application en se basant sur la structure de son flot de contrôle. Pour ce faire, ce module crée un graphe de flot de contrôle à partir des instructions bytecode de l'application. Avantageusement, un tel graphe permet au module l'identification de conditions, de boucles, et/ou de 20 profondeurs de boucles dans le bytecode. La génération d'un tel graphe, permet en outre l'identification par ce module de boucles non-bornées, par exemples des occurrences de boucles de type « while(true) » ou « while(1) » , ainsi que des appels récursifs explicites de méthode, c'est-à-dire d'appels directs à une méthode 25 de même nom et comprenant la même signature. Un tel module permet donc, par sa configuration, l'analyse du bytecode, fournissant à l'utilisateur d'avantage d'informations concernant sa qualité. La configuration de ce module est réalisée grâce au fichier 5 de configuration dans lequel on ajoute les éléments suivants : 30 o élément « «complexity» : cet élément permet à l'utilisateur de spécifier au système 100 de gestion de code octal Java la conduite de l'analyse du bytecode ; o élément cible « target » : par analogie avec les éléments cibles « target » des modules précédemment décrits, cet élément est un 35 sous-élément de l'élément ««complexity» permettant la définition (ou l'exclusion) des classes et corps de méthodes à analyser ; 3029658 22 module d'estimation de temps d'exécution au pire cas. Ce module est configuré pour estimer le temps d'exécution au pire cas dit WCET (acronyme anglais de « Worst Case Execution Time ») du bytecode d'une application. En effet, le fait de changer le code 5 d'une application implique que l'ensemble des analyses initialement conduites à partir de cette base de code ne sont plus valables en temps d'exécution. On veille donc à exécuter ce module à la fin du traitement du bytecode opéré par les autres modules. Avantageusement, ce module utilise le graphe de flot de 10 contrôle d'une application, tout en prenant en compte les types et tailles de données manipulées, pour estimer son temps d'exécution au pire cas. Ce graphe peut être celui créé par le module d'analyse de complexité ou tout autre module si ce module est sélectionné par l'utilisateur, ou sinon directement généré par le module de 15 temps d'exécution au pire cas WCET, basé sur les instructions du bytecode. Ce module est configuré pour utiliser le graphe de flot de contrôle de l'application, qu'il compare avec une table préenregistrée (réalisée au préalable) comprenant des estimations du temps d'exécution de chaque instruction du bytecode. Pour les 20 applications contenant des invocations de méthodes, le module est configuré pour générer une expression représentant le pire temps d'exécution WCET en fonction de ses appels. Pour les méthodes contenant des boucles, le module considère/identifie la partie de l'expression qui dépend de la quantité de fois que la boucle sera 25 exécutée. La configuration de ce module est réalisée grâce au fichier 5 de configuration dans lequel on ajoute les éléments suivants : o élément «wcet» : cet élément permet à l'utilisateur de spécifier la conduite une analyse d'exécution au pire cas WCET du bytecode 30 de l'application ; o élément cible « target » : par analogie avec les éléments cibles « target » des modules précédemment décrits, cet élément est un sous-élément de l'élément «wcet» permettant la définition (ou l'exclusion) des classes et corps de méthodes à estimer. 35 A titres d'exemples, l'ensemble de ces modules sont implémentés en utilisant les classes de la bibliothèque ASM pour la manipulation/le traitement du bytecode Java, et la bibliothèque Javolution pour la 3029658 23 lecture du fichier de configuration 5. Chacun de ces modules 4 d'analyse et de transformation, prend alors pour entrée le fichier 5 de configuration, et lui applique sa méthode de traitement de fichier, afin de lire celui-ci. Avantageusement, la lecture du fichier 5 de 5 configuration permet à chaque module 4 d'analyse et de transformation. de déterminer si la(les) méthode(s) de traitement de bytecode qu'il implémente s'applique(nt) ou non à des éléments, ici des classes du bytecode ; si oui d'extraire les règles de traitement relatives ces classes, 10 c'est-à-dire les règles du fichier 5 de configuration décrivant des analyses et/ou modifications à procéder sur ces éléments. Chaque module 4 d'analyse et de transformation génère alors sur la base des règles de traitement extraites, des règles de configuration qui sont ensuite enregistrées en tant qu'entrée dans une table 15 associative. Avantageusement une règle de configuration se rapporte à un module ainsi qu'à une règle de traitement d'au moins un élément du bytecode, telle une classe. La table associative est donc une représentation en mémoire décrivant les règles de transformations et/ou d'analyses spécifiques à chaque module 4 d'analyse et de 20 transformation. Ainsi, le mécanisme d'analyse et de transformation 3 détermine par comparaison entre chaque entrée de cette table et chaque classe du bytecode Java, les modules 4 d'analyse et de transformation à utiliser pour le traitement du bytecode. Pour rappel, l'origine des classes fournies au mécanisme 3 25 d'analyse et de transformation dépend du contexte : dans un contexte dynamique celles-ci proviennent directement du bytecode Java lors de son chargement dans la machine virtuelle Java, tandis que dans un contexte statique, celles-ci sont identifiées durant l'inspection des fichiers JAR 6. Ainsi, lorsqu'une classe est identifiée par le mécanisme 30 d'analyse et de transformation 3 comme correspondant à une règle spécifique enregistrée, ce dernier transmet le bytecode au module 4 d'analyse et de transformation concerné, ainsi que les règles de configurations associées à ce module. A titre d'exemple, le mécanisme 3 d'analyse et de transformation, transmet les attributs de priorité « 35 priority », date de lancement « release », d'échéance « deadline » des threads au module de remplacement de threads pour traiter le bytecode. Chaque module applique alors sa méthode en fonction des 3029658 24 informations de configuration reçues pour le traitement du bytecode, et retourne en sortie le bytecode de la classe modifiée. Ce bytecode est ensuite utilisé comme entrée pour traitement par le module 4 d'analyse et de transformation suivant, et ainsi de suite. On obtient donc après 5 traitement, une version du bytecode modifié successivement par l'ensemble des modules 4 d'analyse et de transformation. La destination de ce bytecode modifié est finalement fonction du contexte : dans un contexte dynamique les classes traitées sont successivement envoyées à un chargeur de classe, tandis que dans le cas statique 10 l'ensemble des classes traitées sont sauvegardées dans un ou plusieurs nouveaux fichiers JAR 9. Avantageusement, grâce à son aspect multi-modulaire le système 100 de gestion de code octal Java peut contenir une partie ou l'ensemble de ces modules. L'ajout de modules 4 d'analyse et de 15 transformation supplémentaires est par ailleurs envisageable en tant que mode de réalisation. Dans un autre mode de réalisation, si l'on souhaite limiter le nombre de modules 4 d'analyse et de transformation dans le système 100 de gestion de code octal Java, il est aussi possible de modifier directement le fonctionnement d'un module 4 20 d'analyse et de transformation spécifique. Avantageusement, l'architecture proposée permet aussi la création de profils contenant des sous-ensembles de modules (ex : séparation fonctionnelle de méthodes ou de sous-fonctions) parmi tous les modules 4 d'analyse et de transformation implémentés. 25 Selon divers modes de réalisation, le système 100 de gestion de code octal Java implémente à la fois, soit un contexte statique et un contexte dynamique, soit uniquement un contexte dynamique, ou encore uniquement un contexte statique. Selon divers modes de réalisation, le contexte statique peut être 30 réalisé via l'intégration du système 100 de gestion de code octal Java dans des outils de gestion et d'automatisation de production de code, tels que Mayen ou Ant. On veille alors à configurer ces outils, de manière à procéder de manière automatique aux transformations du bytecode après chaque compilation ou 35 production de fichier JAR d'une application ; utilisé directement et de manière autonome, c'est-à-dire en « standalone », à partir d'un fichier JAR 6. 3029658 25 Dans un autre mode de réalisation, on peut, par ailleurs, dans le cadre du contexte statique, pour des modifications jugées « simples » et ne nécessitant pas d'analyse approfondie, proposer à l'utilisateur via le système 100 de gestion de code octal Java, l'utilisation d'un mode 5 « manuel », par exemples l'utilisation d'une interface outil de la machine virtuelle Java dite JVM Tl, acronyme anglais de « Java Virtual Machine Tool Interface », ou encore l'utilisation d'une interface permettant d'effectuer de la programmation orientée aspect, afin d'obtenir directement un code machine déterministe au lieu d'un 10 bytecode. En outre, selon divers modes de réalisation, la communication entre les modules 4 d'analyse et de transformation et le mécanisme 3 d'analyse et de transformation peut être réalisée via des espaces de nommages, un réseau de communication, ou encore via une 15 instanciation réalisée directement dans l'application. Avantageusement, l'ensemble des modes de réalisation décrits permettent la réalisation d'un outil, apte à analyser un bytecode et/ou modifier automatiquement un bytecode Java standard non-temps réel en un bytecode Java temps réel et déterministe. 20 Les modes de réalisations précédemment décrits se réfèrent au standard Java temps réel RTSJ. Cependant, tout autre standard Java temps réel est envisageable, à titre d'exemple, l'utilisation du standard « Safety Critical Java » associé à un ensemble de librairies déterministes. 25 Avantageusement, le système 100 de gestion de code octal Java, via sa modularité, facilite l'ajout de modules d'analyse et/ou de modification du bytecode. Avantageusement, un tel système est facilement configurable par l'utilisateur par le biais du fichier 5 de configuration, lui permettant 30 d'indiquer pour chaque classe les modifications et/ou analyses à effectuer, ainsi que les modules 4 d'analyse et de transformation à utiliser. Un tel système garantit, par ailleurs, la performance en temps d'exécution de toute application. Notamment, l'utilisation d'un module 35 d'analyse de complexité permet une analyse fine du bytecode associé à une application, ce que ne permet pas une simple utilisation de la programmation orientée aspect. En outre, l'utilisation d'un module 3029658 26 d'estimation de temps d'exécution au pire cas permet à l'utilisateur de se tenir informer de la performance de l'application. Avantageusement, un tel système assure aussi la consistance de toute application, de sorte qu'aucune modification ne corrompe le 5 fonctionnement de classes modifiées. REVENDICATIONS1. Système (100) de gestion de code octal Java, permettant la transformation de code octal Java en code octal Java temps réel, ce système comprenant des modules configurés pour réceptionner en entrée un code octal Java ; réceptionner un fichier de configuration (5), ce fichier de configuration (5) spécifiant : o au moins un élément du code octal Java à substituer par un élément de code octal Java temps réel ; o au moins une règle de traitement concernant cet élément, cette règle décrivant au moins un paramètre pour effectuer la substitution de l'élément du code octal vers l'élément de code octal Java temps réel ; - lire le fichier de configuration (5) reçu et extraire du fichier de configuration (5) ladite règle de traitement à appliquer sur l'élément spécifié du code octal Java reçu ; appliquer ladite règle de traitement extraite à l'élément de code octal Java permettant d'obtenir un code octal Java temps réel ; fournir en sortie le code octal Java temps réel obtenu. 2. Système selon la revendication 1, comprenant un module (1) d'analyse et de modification statique et un module (2) d'analyse et de modification dynamique, ces modules étant respectivement configurés pour réceptionner le code octal Java - avant son chargement en mémoire et avant son exécution ; pendant son chargement en mémoire et avant son exécution ; ces modules étant, en outre, configurés pour réceptionner le fichier (5) de configuration ; analyser le code octal Java réceptionné et/ou transformer ce code octal vers un code octal Java temps réel en fonction du fichier (5) de configuration. 3. Système selon la revendication 2, dans lequel le module (1) d'analyse et de modification statique, et le module (2) d'analyse et de modification dynamique comprennent un mécanisme (3) d'analyse et de transformation, le mécanisme (2) d'analyse et de transformation étant 3029658 28 réalisé par au moins un module (4) d'analyse et de transformation, chaque module (4) d'analyse et de transformation comprenant une méthode de traitement de fichier, apte à lire le fichier de configuration (5) et en extraire des informations comprenant ladite 5 règle de traitement, le fichier (5) de configuration étant fourni comme entrée de ce module ; une ou plusieurs méthodes de traitement de code octal Java, aptes à appliquer une analyse et/ou une modification sur au moins un élément d'un code octal Java fourni en entrée de ce module, en 10 fonction des informations extraites du fichier (5) de configuration. 4. Système selon la revendication 3, dans lequel le code octal Java réceptionné par le module (1) d'analyse et de modification statique, comprend pour élément(s) une ou plusieurs classes Java dans au moins une archive Java dite fichier JAR (6) ; 15 - le code octal Java réceptionné par le module (2) d'analyse et de modification dynamique, comprend pour élément(s) une ou plusieurs classes Java directement accessibles ; le module (1) d'analyse et de modification statique et le module (2) d'analyse et de modification dynamique sont configurés pour 20 transmettre le code octal Java et le fichier (5) de configuration réceptionnés au mécanisme (3) d'analyse et de transformation ; le mécanisme (3) d'analyse et de transformation est configuré pour transmettre le fichier (5) de configuration à chaque module d'analyse et de transformation ; 25 - chaque module (4) d'analyse et de transformation est configuré pour lire, via sa méthode de traitement de fichier, le fichier (5) de configuration, et pour extraire en fonction de cette lecture une ou plusieurs règles de traitement à appliquer à une ou plusieurs classes du code octal Java. 30 5. Système selon la revendication 4, dans lequel le mécanisme (3) d'analyse et de transformation est configuré pour enregistrer en tant qu'entrée dans une table, chaque règle de traitement extraite par chaque module (4) d'analyse et de transformation ; 35 - comparer chaque classe du code octal Java réceptionné avec chaque règle de traitement enregistrée dans la table ; 3029658 29 identifier par association entre une classe du code octal Java et une entrée de la table, un ou plusieurs modules (4) d'analyse et de transformation aptes à traiter cette classe ; si au moins un module (4) d'analyse et de transformation est 5 identifié et o si le code octal Java est réceptionné par le module (1) d'analyse et de modification statique, extraire le code octal Java de chaque fichier JAR (6) et le transmettre au(x) module(s) (4) d'analyse et de transformation identifié(s) pour transformer une ou plusieurs 10 de ses classes en classes Java temps réel et obtenir un code octal Java temps réel ; o si le code octal Java est réceptionné par le module (1) d'analyse et de modification dynamique, transmettre le code octal Java au(x) module(s) (4) d'analyse et de transformation 15 identifié(s) pour transformer une ou plusieurs de ses classes en classes Java temps réel et obtenir un code octal Java temps réel; après la transformation d'une ou plusieurs classes du code octal Java par l'ensemble des modules identifiés o sauvegarder le code octal Java temps réel dans un nouveau 20 fichier JAR (9) en remplacement respectif de chaque fichier JAR (6), si le code octal Java est réceptionné par le module (1) d'analyse et de modification statique ; o envoyer le code octal Java temps réel vers le chargeur de classe d'une machine virtuelle Java, si le code octal Java est 25 réceptionné par le module (2) d'analyse et de modification dynamique. 6. Méthode de gestion de code octal Java, permettant la transformation de code octal Java en code octal Java temps réel, cette méthode comprenant 30 une étape de réception d'un code octal Java ; une étape de réception d'un fichier (5) de configuration, ce fichier (5) de configuration spécifiant o au moins un élément du code octal Java à substituer par un élément de code octal Java temps réel ; 35 o au moins une règle de traitement concernant cet élément, cette règle décrivant au moins un paramètre pour effectuer la 3029658 30 substitution de l'élément du code octal vers l'élément de code octal Java temps réel ; une étape de lecture du fichier (5) de configuration reçu ; une étape d'extraction du fichier (5) de configuration de ladite 5 règle de traitement à appliquer sur l'élément spécifié du code octal Java reçu ; une étape d'application de ladite règle de traitement extraite à l'élément de code octal Java permettant d'obtenir un code octal Java temps réel ; 10 - une étape de fourniture du code octal Java temps réel obtenu. 7. Méthode selon la revendication 6, dans laquelle le code octal Java est réceptionné o avant son chargement en mémoire et avant son exécution, et comprend pour élément(s) une ou plusieurs classes Java dans au 15 moins une archive Java dite fichier JAR (6) ; o ou pendant son chargement en mémoire et avant son exécution, et comprend pour élément(s) une ou plusieurs classes Java directement accessibles ; ledit au moins un élément du code octal Java à substituer est 20 une classe Java ; ladite au moins une règle de traitement concernant cet élément est enregistrée dans une table. 8. Méthode selon la revendication 7, dans laquelle la transformation de code octal Java en code octal Java temps réel ainsi 25 que sa fourniture sont réalisées par - l'extraction du code octal de chaque fichier JAR (6) si le code octal Java est réceptionné avant son chargement en mémoire et avant son exécution ; l'application de ladite règle de traitement audit au moins un 30 élément du code octal Java ; si le code octal Java est réceptionné avant son chargement en mémoire et avant son exécution, la création respective pour chaque fichier JAR (6) extrait d'un nouveau fichier JAR (9) comprenant l'ensemble du code octal Java temps réel ; 35 - sinon, l'envoi des classes du code octal Java temps réel vers le chargeur de classe d'une machine virtuelle Java. 3029658 31 9. Produit programme d'ordinateur implémenté sur un support mémoire, susceptible d'être mis en oeuvre au sein d'une unité de traitement informatique et comprenant des instructions pour la mise en oeuvre d'une méthode selon l'une des revendications 6 à 8. 5