En ce qui concerne la traduction du nom des classes, elles vont conserver le même nom. Ainsi, la classe java.lang.Double se nommera aussi java.lang.Double une fois traduite.

Il y a cependant quelques exceptions: Java s'attend à avoir java.lang.Object au sommet de la hiérarchie. Par contre, la CLR aura System.Object au sommet de la hiérarchie des classes. Pour résoudre ce problème, il existe deux solutions:

L'implémentation du traducteur se base sur les classes de J# de Microsoft. Comme ils ont opté pour la première solution dans leur implémentation, c'est cette première façon de faire qui sera discutée ici.

Dans le traducteur, deux cas de correspondance sont considérés:

Les noms des champs peuvent se traduire directement, comme pour le nom des classes. Notons en passant que les instructions relatives aux accès des champs n'ont pas une traduction triviale. Le sujet et traité dans la la section intitulée “Instructions d'accès aux champs”.

De manière générale, les noms des méthodes traduites comportent le même nom que les méthodes JVM. Cependant, la différence qui existe entre les hiérarchies d'objets fait que le nom de certaines méthodes peut parfois être différent. Voir la la section intitulée “Noms des classes” pour l'explication des noms des classes.

Rennomage des méthodes héritées de System.Object.  Comme java.lang.Object est au sommet de la hiérarchie, tous les objets héritent des méthodes définies dans cet objet. Certaines méthodes Java ont un équivalent dans la CLR qui porte un autre nom, et d'autres n'ont pas d'équivalent. Le cas des méthodes qui n'ont pas d'équivalent dans la CLR est détaillé au paragraphe suivant. Les méthodes qui ont un équivalent ne sont pas nombreuses:

L'algorithme est le suivant: Si on tente d'accéder à une des méthode JVM décrite dans la table ci-dessus (avec la bonne signature), on la renomme vers le son équivalent de la CLR.

Cette façon de faire impose une restriction sur les méthodes d'une classe: une classe ne peut pas contenir simultanément une méthode JVM ci-dessus et son équivalent CLR. Par exemple, il n'est pas permis d'avoir simultanément une méthode nommée MemberwiseClone et clone (avec les signatures correspondantes). Un contrôle doit donc être effectué pour appliquer cette restriction..

Redirection des méthodes vers des classes auxiliaires.  Le fait de substituer les objets JVM avec des objets CLR implique qu'il faudra rediriger certains appels de méthodes. Pour résoudre ce problème, on utilise des classes annexes, qui contiennent toutes les méthodes des objets JVM originaux, et on redirige les appels vers ces classes. Voici un exemple de ce qui se passe lors de l'appel de la méthode trim() sur un object de la classe java.lang.String qui a été substitué par System.String.

Nous avons vu comment traduire les noms des classes et membres, il reste maintenant la traduction des modificateurs. Les deux tableaux ci-dessous donnent l'équivalence entre les modificateurs des deux plates-formes. On peut noter que la sémantique des droits d'accès n'est pas toujours conservée lors de la traduction, car la notion de paquetage n'existe pas dans la CLR. Il peut donc être possible d'avoir des droits d'accès moins restrictifs dans le code traduit que le code Java original.

Accessibilité dans la CLR. L'accessibilité des membres dans la CLR est définie par deux règles: Family et Assembly. Familiy signifie que le membre est accessible par toutes les classes qui étendent le type. Assembly veut dire que le membre est accessible pour tous les types du même assemblage. Il est aussi possible d'avoir une combiaison des deux concepts: Family and Assembly, et Family or Assembly.

Accessibilité dans la JVM. La JVM ne comportant pas de notion d'assemblage, il n'y a pas d'équivalent pour l' Assembly de la CLR. Le détail est donné dans les tables ci-dessous:

Pour faire une traduction de programmes Java, il est nécessaire de traduire la libraire standard de Java. On pourrait penser qu'un fois le traducteur fonctionnel, il suffirait de traduire le bytecode de toute la librairie. Il se pose cependant un autre problème: la librairie comporte des méthodes natives, i.e. des méthodes qui ne n'ont pas de code JVM, mais qui existent en langage machine natif.

Pour résoudre ce problème, il existe plusieurs solutions:

C'est la deuxième solution qui a été utilisée dans le traducteur, en utilisant la librairie J# développée par Microsoft. La limitation de cette solution est que la librairie Java de J# implémente la version 1.1.4 du JDK. Par conséquent, certaines classes et méthodes apparues dans les versions plus récentes du JDK ne sont pas disponibles.

Les classes internes en Java sont apparues quelques temps après la sortie du langage. Comme la notion de classes interne n'existe pas pour la JVM, les classes internes doivent être traduites en classes globales par les compilateurs Java.

Ainsi, la traduction directe des classes internes fonctionnera à l'identique sur la CLR. Cependant, vu que cette dernière possède la notion de classes interne, il serait théoriquement possible de traduire ces classes internes Java en celles de la CLR.

Dans l'implémentation, la transformation des classes internes JVM en classe internes ("nested classes") CLR n'est pas implémentée.

La JVM comporte moins de types simples que la CLR. Cette dernière comporte des types signés et non signés, alors que la JVM ne comporte seulement des types signés, à l'exception du type char, non signé. La correspondance des types simples ne pose donc pas de problèmes particuliers.

Gestions des types références dans les variables locales. Le fait que les slots ne sont pas typés peut poser un certain nombre de problèmes lorsque plusieurs types références différents sont stockés dans un même slot. En effet, il peut se produire deux cas de figure:

Pour mieux comprendre le problème, voici un exemple simple où un même slot se voit attribuer deux types différents au cours de la méthode.

Algorithme naïf de gestion des types référence dans les slots. Comme on peut le voir dans l'exemple précédent, on pourrait se dire que l'algorithme suivant permettrait de résoudre le problème: on conserve un type référence pour chaque slot. Chaque fois que l'on stocke dans le slot un type qui n'est pas un sous type du type courant, on utilise un nouveau slot. Cet algorithme fonctionnerait bien pour l'exemple précédent, cependant il existe des cas pour lesquels l'algorithme est erroné. Voici qui ne fonctionne pas avec cet algorithme:

Si on applique l'algorithme précédent, on va tout d'abord affecter le type B au slot 1 à l'instruction 7. Lors de l'affectation à l'instruction 15, on voit que le type est différent et n'est pas une sous-classe. On va donc utiliser une autre variable locale. Ceci n'est pas correct, car le slot doit être partagé.

Algorithme actuel de gestion des types références . Pour résoudre ce problème, il y a deux possibilités

C'est cette deuxième solution qui est utilisée ici, ainsi que dans l'implémentation, car la première se montre trop complexe à réaliser.

Comme mentionné plus haut, il faut récupérer l'information concernant les cadres entrants et sortants pour chaque instruction qui accède aux slots JVM. Une manière de faire est d'exécuter une vérification du bytecode comme spécifié dans la spécification de la machine virtuelle Java, tout en mémorisant les types accédés. L'algorithme en question ne sera pas détaillé ici, il peut être trouvé dans la spécification de la machine virtuelle Java [[JVM]]. Il faudra ajouter à l'algorithme une sauvegarde des cadres sortants et entrants pour chaque instruction.

La première phase de l'algorithme consiste à allouer les variables locales qui seront utilisées pendant la phase de production de code. Pour ce faire, une structure de donnée décrivant chaque slot est utilisée:

Des fonctions sont utilisées pour allouer les variables locales, et faire le traitement adéquat lorsque l'on rencontre une instruction accédant à un slot.

  alloue une nouvelle variable locale:

      allocateLocalVar(Type : t) : LocalVar {
        // génère une variable locale IL du type t, et la retourne
      }

  informe qu'un certain type sur un slot a été accédé:
  
      setAccessedType(ArgOrLocal : kind, int: slot, int: pc, Type: t) 

         if types.containsReferenceType() 
           oldRefType = types.getReferenceType()
           t = commonSuperType( t, types.getReferenceType() )

           types.replace ( oldRefType, t );

         end if

         if slots[slot].types.containsKey(t)  
            slots[slot].positionToLocal.set( pc =>
                                            (kind, slots[slot].types(t)));
         else 
            localVar = allocateLocalVar(t)
            slots[slot].types.set( t => localVar)
            slots[slot].positionToLocal.set( pos => (kind, localVar) )
         end if
            

Avec les structures de donnée et les fonctions définies, il est maintenant possible de définir l'algorithme d'analyse en question:

  int : argIndex = 0

  if method.isStatic()
    setAccessedType(argIndex++, 0, method.classType());
    foreach (argument in  method.arguments) {
       setAccessedType(ARGUMENT, argIndex++, 0, argument.Type);
       if (argument.Type == double || argument.Type == long)
         argIndex++;
  }



  foreach (instruction in code) {
     pc = instruction.pc
     switch (instruction)
       
       case ?Load (slot):
       case ?Store (slot):
          setAccessedType(LOCALVAR, slot, pc, frames[pc][slot].type);

     end switch

  } 
              

La deuxième partie de l'algorithme se déroule pendant la phase de production du bytecode. C'est à ce moment qu'il faudra connaître si les instructions d'accès se font sur un paramètre ou une variable locale, ainsi que la variable locale utilisée.

            
  foreach (instruction in code) {
     pc = instruction.pc

     switch (instruction)
       
       case ?Load (slot):
       case ?Store (slot):

         switch (slots[slot].positionToLocal)
           case (ARGUMENT, localvar)
             switch (instruction)
               case ?Load (slot):
                  ig.Emit(ldarg, localvar)
               case ?Store (slot):
                  ig.Emit(starg, localvar)
             end switch
           case (LOCALVAR, localvar)
             switch (instruction)
               case ?Load (slot):
                  ig.Emit(ldloc, localvar)
               case ?Store (slot):
                  ig.Emit(stloc, localvar)
             end switch
           end switch
         end switch   
  } 

          

Utilisation de variables locales auxiliaires.  Certaines instructions nécessitent des variables locales supplémentaires pour la traduction. Par exemple l'instruction iinc a besoin d'une variables locale pour stocker la valeur intermédiaire que l'on a incrémenté. Un algorithme naïf serait d'allouer des variables locales lors de la traduction de l'instruction. Cette façon de faire à le désavantage de ne pas réutiliser les variables locales, et pourrait avoir comme conséquence une consommation excessive de variables.

              
  fonction qui enregistre que l'on veut utiliser un certain nombre de 
    variables locales à une position donnée.
    Elle est utilisée pendant la phase d'analyse

  needTypes(int : position: Type[] : types) {

    ...
  }
  
  fonction qui retourne un tableau de variables locales pour une position donnée
     Elle est utilisée pendant la phase de production de code

  getAuxiliaryLocals(int : position) : LocalVar[] {

  }

            

Ce qu'il faut ajouter à la phase d'analyse sera donc:

  ...
  case {instruction qui a besoin de variables locales}:
    needTypes(pc, [ Type1, Type2, ...]);
   
  ...
            

De même, pendant la phase de production du code, il faudra ajouter:

              
  case {instruction qui a besoin de variables locales}:
    types = getAuxiliaryLocals(pc)
    
    ...   
     // Utilisation du tableau types pour utiliser les
     // variables locales disponibles
    ...          
            

Dans la JVM, il existe deux instructions pour gérer les switch: lookupswitch et tableswitch. Dans la CLR, il n'en existe qu'une seule: switch.

Tableswitch est une instruction à longueur variable permettant d'implémenter une table de saut d'index croissants (n, n+1, n+2, ...). L'instruction CLR switch est très similaire à l'exception près que la table des index doit commencer à l'index 0, alors que la JVM peut spécifier l'index de départ. Pour la traduction, il suffit de soustraire un offset correspondant avant d'émettre l'instruction switch.

L'instruction lookupswitch implémente une table de sauts d'index non forcément contigus. Comme il n'y a pas d'équivalent direct pour la CLR, on peut envisager plusieurs solutions. La solution la plus simple est simplement un enchaînement de tests conditionnels et de branchements, comme dans l'exemple qui suit:

Une deuxième façon de traduire une telle instruction lookupswitch est d'utiliser un algorithme dichotomique. L'algorithme n'est pas détaillé ici, car c'est la première façon de faire qui a été utilisée dans l'implémentation. Voici cependant un exemple pour comprendre le fonctionnement:

Performance des algorithmes.  L'enchaînement de tests conditionnels est l'algorithme le moins performant, car il est de l'ordre de O(n). En revanche, l'algorithme par dichotomie sera de l'ordre de O(log n). Dans le cas de switch très long exécutés régulièrement, la différence peut être notable. Cependant, la plate-forme .Net fait un usage extensif de la compilation "juste à temps" (JIT). Il est donc fort possible que la première solution soit optimisée par le compilateur, et que ses performances soient équivalentes à la solution par dichotomie.

La traduction des exceptions de la JVM vers la CLR est un problème délicat. En effet, la CLR place beaucoup de contraintes sur les instructions et leur comportement par rapport aux blocs d'exception, alors que la JVM est assez libérale sur le sujet. De plus, les deux systèmes ont des mécanismes de fonctionnement qui diffèrent sur certains points, comme la gestion de comment parvenir vers le bloc finally. Pour mieux comprendre les mécanismes impliqués ici, les contraintes imposées sur les instructions des deux plates-formes seront tout d'abord discutées. Ensuite, les mécanismes qui diffèrent seront abordés, comme la gestion des instructions relatives aux blocs finally.

La CLR possède un mécanisme de gestion des exceptions plus étendu que la JVM. Elle peut contenir 4 blocs de gestion différents: finally, fault, type-filtered et user-filtered (la description exacte se trouve dans la spécification). Pour la JVM, elle possède deux types de blocs de gestion: les blocs catch et finally. Dès lors, la correspondance logique de traduction est indiquée dans le tableau suivant:

La CLR impose des restrictions beaucoup plus strictes que la JVM concernant le flot d'exécution. Les contraintes exactes sont dans la spécification de la CLR, partition I [[Ecma]]. De manière informelle, on peut les décrire comme suit: on ne peut rentrer dans un bloc que par la première instruction, et dans un gestionnaire seulement s'il y a eu une exception. On ne peut sortir d'un bloc d'exception que par une instruction leave.

De telles contraintes n'existent pas dans la JVM, ce qui peut poser problème pour toutes les instructions de saut. Pour résoudre ce problème, il faut analyser la destination du saut: si la destination reste dans le bloc en cours, il n'y a pas de traitement spécifique à faire. Si la destination sort du bloc, et que l'instruction est un saut conditionnel, il faudra utiliser une instruction de test avec une instruction leave, sinon seulement une instruction leave.

Un problème important dans le processus de traduction est le codage des blocs de gestion des exceptions. Dans la CLR, tous les gestionnaires d'exceptions sont spécifiés avec leurs adresses de départ ainsi que leur adresse de fin. Au contraire, la JVM n'encode pas les positions de fin des gestionnaires d'exception. Ceci fait qu'il est nécessaire de retrouver les positions de fin des blocs d'exception pour pouvoir les traduire vers la CLR. Cette étape n'est pas triviale et il est nécessaire de développer des algorithmes et heuristiques pour reconstituer cette information.

Recherche des fins de blocs.  La recherche des fins des gestionnaires ("handlers") d'exception de la JVM est très difficile dans le cas général, car la JVM ne pose pas de contraintes par rapport à l'emplacement des blocs de gestion des exceptions. Il serait possible, par exemple, d'avoir un gestionnaire d'exception qui se situe avant le bloc try qu'il protège. Dès lors, un algorithme gérant toutes les situations devrait faire une analyse approfondie de la structure du code.

Une simplification majeure d'une telle recherche est de partir du principe que le compilateur va placer les blocs d'exceptions dans un ordre séquentiel, avec le bloc try suivit d'éventuellement plusieurs blocs catch et finalement d'un block finally facultatif. Avec cette hypothèse, on trouve 3 cas de figure, listé ci-dessous:

De manière générale, on peut supposer que la fin de tous les blocs non terminaux se situe juste avant l'instruction du bloc suivant.

Algorithme de recherche de la fin des blocs d'exceptions.  Une étape importante des algorithmes de traduction des exceptions est de trouver la fin du bloc d'exception. Le principe de l'algorithme est de parcourir les instructions à partir d'une certaine position, afin de mémoriser la position la plus élevée de la destination des sauts. Il considère aussi une valeur minimale de destination à observer, nommée lowestBound. Le détail de l'algorithme est donné ci-dessous.

            

  if catchBlocks.length > 0
    lowestBound = catchBlocks[catchBlocks.length - 1].start

  if finallyBlock.start != NULL
    lowestBound = finallyBlock.start

  pc = startPc
  endPos = instructions.lastInstructionOffset
  while pc < endPos; do

    switch (code[pc])
      case if*  (targetPc) 
      case goto (targetPc)

        if targetPc < endPos && targetPc > lowestBound
          endPos = targetPc

    pc++
  end while

                

Algorithme de recherche du début des instructions du bloc finally à traduire.  Pour illustrer le problème, un exemple va nous permettre de mieux comprendre. L'exemple ci-dessous comporte un bloc d'exception try-catch-finally, avec les gestionnaires mis en évidence:

Sur cet exemple, on remarque que les instructions au début du bloc finally n'ont pas besoin d'être traduites, car elles servent au mécanisme du jsr. Il faut donc développer un algorithme qui nous permette de connaître le début des instructions du bloc finally à traduire.

Le principe de l'algorithme est de parcourir toutes les instructions à partir d'une certaine position, et de mémoriser la destination des instructions jsr.

                

  finallyStart = -1
  pc = startPc

  while pc < lastPc && pc != finallyStart; do
    
    switch code[pc]
      case JsrInstruction (target)
         finallySTart = target
    end switch
  end while
  
  return finallyStart


                

              

Les machines virtuelles JVM et CLR peuvent lancer des exceptions lorsque certaines conditions ne sont pas vérifiées, ou lors d'erreurs. Par exemple, une division par zéro va lancer une exception java.lang.ArithmeticException dans la JVM, et une exception System.DivideByZeroException dans la CLR. Une traduction directe des classes des gestionnaires d'exceptions ne fonctionnera dans tous les cas. En effet, si un programme dépend sur le fait de rattraper une exception Java de la machine virtuelle, il ne la verra pas si elle porte un autre nom lors de son lancement sur la CLR. Il faut donc implémenter un traitement supplémentaire pour ces exceptions, qui permet de fonctionner dans tous les cas.

La solution adoptée dans le compilateur J# est d'utiliser les mécanismes des filtres (gestionnaires filter). Si on remarque une instruction problématique lors de la traduction, il suffit d'ajouter un filtre qui va recréer une exception JVM correspondante, et va la relancer. De cette manière, le comportement sera le même que sur une plate-forme Java.

Le support des filtres n'étant pas encore implémenté dans la librairie MSIL, cette fonctionnalité n'est actuellement pas implémentée.

Toutes les instructions arithmétiques de la JVM ont un équivalent pour la CLR. Il n'y a donc pas de problèmes particuliers au niveau de la traduction.

De même que les instructions arithmétiques, les instructions de conversion ne posent pas de problèmes particuliers, car elles ont toutes un équivalent direct en CLR.

Les instructions d'accès aux tableaux sont très similaires sur les deux plates-formes. Elles nécessitent sur la pile une référence à un tableau, un index, et une valeur dans le cas d'un store. La valeur est ensuite stockée ou récupérée à l'index fourni.

Les instructions de comparaison permettent de comparer deux nombres value1 et value2 sur la pile, et renvoient 1, 0 ou -1:

La CLR ne comporte pas d'équivalent pour ces instructions, c'est pourquoi il faut les traduire avec plusieurs comparaisons et un saut.

Voici un exemple de traduction:

Les instructions de concurrence monitorenter et monitorexit se traduisent facilement, en appelant les méthodes statiques de la librairie de base correspondante.