Tutoriel sur la compréhension de la machine virtuelle Java

Pour ajouter des constantes dans le pool de constantes, nous allons ajouter une méthode par constante qui prendra les mêmes paramètres que le constructeur de la constante et qui retournera l'index de la constante dans le pool de constantes.

Par exemple pour la constante ConstantUTF8 :

public int getCurrentCPIndex() {
  return this.constantPool.size() - 1;
}
 
public int addConstantUTF8(final String value) {
  final Constant.UTF8 constant = new Constant.UTF8(value);
  this.constantPool.add(constant);
  return this.getCurrentCPIndex();
}

Néanmoins, arrêtons-nous quelques secondes. Si l'on écrit et exécute le test unitaire ci-dessous, nous constatons qu'il est correct :

@Test
public void stringEquality() {
  final String s1 = "Bonjour";
  final String s2 = "Bonjour";
 
  Assert.assertEquals(s1, s2);
  Assert.assertTrue(s1 == s2);
}

Les deux assignations peuvent être traduites en PJB de la manière suivante :

ldc "Bonjour"
astore_0
ldc "Bonjour"
astore_1

Dans un fichier .class, les instructions ldc pointent vers l'index d'une constante de type ConstantString, elle-même pointant vers une constante de type ConstantUTF8. Dans le cas présent, les deux instructions pointeront vers la même constante.

Mais new String("Bonjour") != new String("Bonjour"). Et ceci est aussi valable pour les types numériques :

5 == 5

et

Integer i1 = 5;
Integer i2 = 5;
i1 == i2;

mais

Integer i1 = 5_000;
Integer i2 = 5_000;
i1 != i2;

et

new Integer(5) != new Integer(5)

Nous le savions, Java aime faire les choses simplement et sans surprise…

Pour les types primitifs, nous comparons des valeurs, par conséquent elles sont égales. Jusque-là, rien de très surprenant. En revanche pour les objets les choses sont bien différentes.

Commençons par les objets de type String. Toutes les littérales de type String - dont la chaîne de caractères est identique - ont toujours la même référence quel que soit l'endroit de leur déclaration.

Les littérales numériques sont quant à elles autoboxées. C'est-à-dire que l'assignation Integer i = 5 est compilée en Integer i = Integer.valueOf(5). Or, comme indiqué dans la javadoc, la méthode valueOf() a un cache initialisé au chargement de la classe, contenant des objets de type Integer pour toutes les valeurs comprises entre -128 et 127 (oublions la fin de la phrase « et peut mettre en cache d'autres valeurs hors de cet intervalle »). Ceci explique pourquoi dans le premier cas (pour la valeur 5) deux primitifs autoboxés en Integer sont égaux et dans le second (pour la valeur 5000) ne le sont pas.

Pour le type Long, bien que le système de mise en cache ne soit pas requis, il est bien présent.

En revanche, il n'y a aucun mécanisme similaire pour les types Float et Double.

Néanmoins, il est déconseillé de se reposer sur l'autoboxing/unboxing pour effectuer une comparaison, il est préférable de faire des comparaisons uniquement sur des types primitifs.

Note : les tests présentés ci-dessus peuvent être retrouvés dans la classe suivante : EqualityTest

Nous en venons à la conclusion que dans le pool de constantes d'un fichier .class, chaque constante peut être unique, sans que cela ne pose de problèmes. Il nous faut donc adapter les méthodes addConstantXYZ() en conséquence.

Prenons quelques exemples :

private int addConstant(final ConstantPoolEntry constant) {
  final int index = this.constantPool.indexOf(constant);
 
  if (index == -1) {
    this.constantPool.add(constant);
    return this.getCurrentCPIndex();
  } else {
    return index;
  }
}
 
public int addConstantUTF8(final String value) {
  final Constant.UTF8 constant = new Constant.UTF8(value);
  return this.addConstant(constant);
}
 
public int addConstantString(final int utf8Index) {
  final Constant.String constant = new Constant.String(utf8Index);
  return this.addConstant(constant);
}
 
public int addConstantLong(final long value) {
  final Constant.Long constant = new Constant.Long(value);
  final int index = this.addConstant(constant);
  this.constantPool.add(null);
  return index;
}
 
public int addConstantDouble(final double value) {
  final Constant.Double constant = new Constant.Double(value);
  final int index = this.addConstant(constant);
  this.constantPool.add(null);
  return index;
}

Comme mentionné dans l'article précédent, les constantes ConstantLong et ConstantDouble prennent deux index dans le pool de constantes (n et n+1). Dans le fichier .class généré, l'index n+1 n'est en réalité pas utilisé. Imaginons que nous ajoutons une constante ConstantInt à l'index 11, puis une constante ConstantLong à l'index 12, la prochaine constante sera à l'index 14.

De plus, nous devons surcharger dans toutes les classes de constantes, les méthode hashCode() et equals().

Tests Unitaires

Les champs thisClass et superClass ont pour valeur l'index d'une classe de type ConstantClass dans le pool de constantes. Dans cette version de PJBA, toute classe aura pour parent java.lang.Object. Nous allons donc pouvoir valoriser le champ dans le constructeur. Quant au champ thisClass, plusieurs solutions s'offrent à nous. Ajouter un paramètre de type String au constructeur prenant le nom complètement qualifié de la classe ou ajouter un setter, ce qui nécessitera en amont de créer une constante ConstantUTF8, puis une constante ConstantClass et de passer au setter l'index de cette dernière. Bien évidemment, nous pouvons mettre en place les deux solutions, néanmoins la première semble convenir à la majorité des situations.

public ClassFile(final String fullyQualifiedName) {
  //...
 
  // This
  final int classNameIndex = this.addConstantUTF8(fullyQualifiedName);
  this.thisClass  = this.addConstantClass(classNameIndex);
 
  // Parent - Codé en dur pour l'instant
  final String superName = "java/lang/Object";
  final int superNameIndex = this.addConstantUTF8(superName);
  this.superClass = this.addConstantClass(superNameIndex);
 
  //...
}

Avant de continuer, ajoutons deux champs qui nous seront utiles lors de la génération de nos fichiers .class, le répertoire dans lequel devra être généré le fichier (le package en terme Java) et le nom de la classe. Nous avons ces deux informations dans le nom complètement qualifié d'une classe (le paramètre du constructeur). Il nous faut donc le découper en deux parties, sachant qu'une classe n'est pas obligatoirement dans un package.

private String className;
private String directories;
 
private void parseName(final String fullyQualifiedName) {
  int index = fullyQualifiedName.lastIndexOf(Ascii.SLASH);
 
  if (index >= 0) {
    this.directories = fullyQualifiedName.substring(0, ++index);
    this.className = fullyQualifiedName.substring(index);
  } else {
    this.className = fullyQualifiedName;
  }
}

La méthode parseName() sera appelée au début du constructeur.

Le tableau et les listes sont aussi initialisés dans le constructeur :

public ClassFile(final String fullyQualifiedName) {
  //...
 
  this.interfaces = new int[0];
  this.fields = new PjbaLinkedList<>();
  this.methods = new PjbaLinkedList<>();
  this.attributes = new PjbaLinkedList<>();
 
  //...
}

Pour l'instant, nous nous intéresserons uniquement à la liste d'objets de type Method, qui seront ajoutés très simplement à l'aide d'une méthode addMethod() :

public void addMethod(final Method method) {
  this.methods.add(method);
}

Source

Dans le code ci-dessus, une méthode demande une explication, puisque nous ne l'avions pas vue jusqu'à présent. La méthode countParameters() compte le nombre de paramètres d'une méthode en analysant son descripteur. Pour un être humain, cette méthode n'est pas forcément utile, puisque nous pouvons indiquer directement le nombre de paramètres de la méthode que nous sommes en train de créer. Néanmoins, il n'en va pas de même pour l'analyseur syntaxique que nous créerons prochainement.

Pour rappel, un descripteur peut avoir la forme suivante :

([[[Ljava.lang.Object;[[LObject;)V

ce qui donnerait en Java :

void nomDeLaMethode(java.lang.Object[][][], Object[][])

En repartant d'une situation plus simple, les types primitifs sont assez simples à analyser. Les types long et double prennent deux cases dans les variables locales, les autres une seule et void zéro.

Pour les classes, nous savons qu'elles commencent par la lettre « L » et se terminent par un point-virgule « ; ».

En revanche, les tableaux sont représentés par un crochet ouvrant « [ » suivi du type du tableau, et pour les tableaux à plusieurs dimensions les crochets se suivent mais comptent toujours pour un seul paramètre. Le cas extrême est celui illustré ci-dessus, un tableau à plusieurs dimensions d'objets.

La tâche étant légèrement complexe, le code de la méthode l'est aussi. Sachant que pour l'occasion, l'optimisation du code a été mise en avant.

L'idée est de parcourir la chaîne en analysant chaque caractère, d'incrémenter le nombre de paramètres si le caractère est une lettre représentant un type ou s'il s'agit du premier crochet rencontré et d'ignorer tous les autres caractères.

En ignorant le cas des tableaux, le code de la méthode est le suivant (Le détail de chaque étape est en commentaire) :

private static final String ENCODING = "UTF-8";
 
public int countParameters(final String methodDescriptor) {
  try {
    // Nous transformons la chaîne de caractères en tableau de bytes
    final byte[] descriptor = methodDescriptor.getBytes(ENCODING);
 
    // Le premier caractère est une parenthèse ouvrante
    int index = 1;
    // Représente le nombre de paramètres du descripteur
    int locals = 0;
    // Permet de savoir si le compte a changé entre les différentes itérations
    int previousLocals = locals;
 
    for (;;) {
      byte character = descriptor[index++];
 
      switch (character) {
        case Ascii.UPPERCASE_B: // byte
        case Ascii.UPPERCASE_C: // char
        case Ascii.UPPERCASE_F: // float
        case Ascii.UPPERCASE_I: // int
        case Ascii.UPPERCASE_S: // short
        case Ascii.UPPERCASE_Z: // boolean
          locals++;
          break;
        case Ascii.UPPERCASE_J: // long
        case Ascii.UPPERCASE_D: // double
          locals += 2;
          break;
        // Nous ignorons tous les caractères jusqu'au point-virgule
        case Ascii.UPPERCASE_L: // reference
          locals++;
          while (index < descriptor.length
              && (character = descriptor[index++]) != Ascii.SEMICOLON);
          break;
      }
 
      // Nous avons rencontré un crochet fermant ou un V
      // Il n'y a plus rien à compter
      if (locals == previousLocals) {
        break;
      }
 
      previousLocals = locals;
    }
 
    return locals;
  } catch (UnsupportedEncodingException e) {
    throw new RuntimeException("Should never happen", e);
  }
}

En introduisant les tableaux, le code ci-dessus a besoin d'être modifié. Si nous rencontrons un crochet, nous ajoutons 1 à la variable locals, puis nous devons ignorer les crochets suivants ainsi qu'un type qui peut être représenté par un ou plusieurs caractères. Pour ce faire, nous devons utiliser une méthode récursive qui contiendra le switch. Le problème est que nous mettons à jour deux variables, index et locals. Utiliser un objet est généralement la solution la plus simple. Néanmoins, dans un tel cas, utiliser un objet mutable rend le code difficile à lire et à maintenir. Nous allons donc choisir une autre solution, la méthode de packing/unpacking (rassembler plusieurs valeurs dans une même variable) que nous avons déjà vue dans la partie Manipulation de la pileManipulation de la pile. Nous savons que les variables locales ne peuvent pas excéder 65 535 éléments (soit un short non signé) et qu'un tableau en Java ne peut avoir plus de 2 147 483 647 éléments (soit un int), or à moins d'être complètement dérangé, et dans ce cas il est conseillé d'aller consulter, le descripteur d'une méthode ne fera pas plus de deux milliards de caractères. De fait, un long conviendra parfaitement. Les 32 premiers bits seront utilisés pour l'index et les 32 derniers pour le nombre de paramètres.

La méthode précédente est à présent découpée en deux méthodes :

public int countParameters(final String methodDescriptor) {
  try {
    final byte[] descriptor = methodDescriptor.getBytes(ENCODING);
 
    int index = 1; // Step over the first element: Left parenthesis
    int locals = 0;
    int previousLocals = locals;
 
    for (;;) {
      final long pack = countOneParameter(descriptor, index, locals);
      locals = (int) (pack & 0xffff);
      index = (int) (pack >>> 32);
 
      // We encountered a right bracket or a void
      if (locals == previousLocals) {
        break;
      }
 
      previousLocals = locals;
    }
 
    return locals;
  } catch (UnsupportedEncodingException e) {
    throw new RuntimeException("Should never happen", e);
  }
}
 
private long countOneParameter(byte[] descriptor, int index, int locals) {
  byte character = descriptor[index++];
 
  switch (character) {
    case Ascii.UPPERCASE_B: // byte
    case Ascii.UPPERCASE_C: // char
    case Ascii.UPPERCASE_F: // float
    case Ascii.UPPERCASE_I: // int
    case Ascii.UPPERCASE_S: // short
    case Ascii.UPPERCASE_Z: // boolean
      locals++;
      break;
    case Ascii.UPPERCASE_J: // long
    case Ascii.UPPERCASE_D: // double
      locals += 2;
      break;
    case Ascii.LEFT_BRACKET: // array
      locals++;
      final long pack = this.countOneParameter(descriptor, index, 0)
      index = (int) (pack >>> 32);
      break;
    case Ascii.UPPERCASE_L: // reference
      locals++;
      while (index < descriptor.length &&
             (character = descriptor[index++]) != Ascii.SEMICOLON)
        ;
      break;
  }
 
  // Locals maximum value = 65,535
  // Arrays maximum size in Java = 2,147,483,647
  return (((long) index) << 32) | locals;
}

Source

Si l'on fait l'impasse sur le packing/unpacking qui n'a rien de particulier en soi, le seul changement est l'ajout d'un case dans le switch :

case Ascii.LEFT_BRACKET: // Array
  locals++;
  final long pack = this.countOneParameter(descriptor, index, 0);
  index = (int) (pack >>> 32);
  break;

Nous prenons bien en compte le premier crochet, puis appelons la méthode countOneParameter() récursivement en ignorant le paramètre locals. Nous avons les cas suivants :

• si l'élément suivant est un type primitif, l'index est incrémenté de 1 ou 2 ;
• s'il s'agit d'un objet, l'index est incrémenté d'autant de caractères le constituant ;
• s'il s'agit à nouveau d'un ou plusieurs crochets ouvrants, nous aurons des appels récursifs successifs.

Tests unitaires