Tout le code présenté dans cette partie et les suivantes est disponible sur Github. Chaque partie aura son propre tag et sa propre branche, contenant aussi le code des parties précédentes. La branche master contiendra le code du dernier article publié.

Par exemple, le code de cette partie est disponible sur le tag et la branche nommés « part00 » et la branche master jusqu'à la publication de la partie suivante (c'est-à-dire la semaine prochaine).

Avant de voir un peu de code, il nous faut évoquer les outils qui nous seront nécessaires tout au long de ces chapitres pour compiler et tester les exemples.

I-D-2-a. ANT▲

Ant offrant une liberté infinie, il est nécessaire d'adopter certaines conventions. L'organisation standard d'un projet aura donc la forme suivante :

project
|  +- 01_src (code source)
|  |  +- main
|  |  |  +- java
|  |  |  +- resources
|  |  +- test
|  |  |  +- java
|  |  |  +- resources
|  +- 02_build (généré)
|  |  |  +- classes
|  |  |  +- junit-data
|  |  |  +- junit-reports
|  |  |  +- test-classes
|  +- 03_dist (généré)

Cette série de parties allant couvrir de nombreux sujets différents, nous allons avoir plusieurs projets, il nous faut donc un niveau supplémentaire :

jvm_hardcore
|  +- 01_conf (fichiers de configuration Ant)
|  +- 02_libs (*.jar)
|  +- 03_projects
|  |  +- mystery
|  |  +- [...]
|  +- 04_archives (tous les JARs générés par le projet)

Le code de cette application n'a rien d'extraordinaire. Mais vous pouvez tout de même le consulter, ainsi que les tests unitaires. Néanmoins, la méthode byteToHex() mérite notre attention.

La méthode byteToHex() est utilisée pour dumper les fichiers .class. Après ouverture du fichier dont le chemin est passé en paramètre - de l'application -, nous récupérons un tableau d'octets que nous passons à la méthode. Chaque élément du tableau est converti en valeur hexadécimale ASCII de deux caractères ajoutés dans un nouveau tableau d'octets. Ce nouveau tableau d'octets est ensuite retourné par la méthode, puis écrit dans un nouveau fichier.

Pour comprendre la méthode byteToHex(), il faut tout d'abord prendre conscience que manipuler un fichier signifie généralement manipuler un tableau d'octets (nous verrons plus tard qu'il y bien d'autres solutions - parfois plus simples -, mais ici l'objectif étant éducatif nous allons souvent recréer la roue).

Pour rappel, un octet (ou un byte) est égal à huit bits ou deux nibbles. En hexadécimal, quatre bits (ou un nibble) sont représentés par un caractère de 0 à F (dans cet exemple nous nous contenterons des lettres en majuscules). Par conséquent, convertir un octet en hexadécimal ASCII de deux caractères est théoriquement extrêmement simple, puisqu'il suffit de découper notre octet en deux parties de quatre bits chacune représentée par un caractère. Cependant, en pratique, il y a quelques pièges à éviter.

En prenant par exemple le nombre 94, nous pouvons écrire un test unitaire de la façon suivante :

@Test
public void byteToHex0Test() {
    // 94(10) = 5E(16) = 0101 1110(2)
    final byte number = 94;
    final byte[] hex = byteToHex0(number);
 
    Assert.assertArrayEquals(new byte[]{5, 14}, hex);
}

Source

Dans ce test, nous obtenons deux nombres décimaux. Pour les remplacer par des caractères, il suffit de prendre le tableau suivant :

byte[] chars = {'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'};

Les nombres décimaux sont utilisés comme index du tableau :

chars[5] == '5'
chars[14] == 'E'

Il nous faut à présent implémenter la méthode

byte[] byteToHex0(byte number)

La première question qui nous vient à l'esprit est : « Comment découper un octet en deux nibbles ? »

Pour y répondre, nous devons tout d'abord représenter le nombre décimal au format binaire (0101 1110). Nous souhaitons donc avoir d'un côté « 0101 » et de l'autre «  1110 ». Pour récupérer les quatre premiers bits, le plus simple est de décaler les bits de quatre positions vers la droite :

94 >> 4 // 0101 1110 >> 4 = 0000 0101

quant aux quatre derniers, nous pouvons masquer les quatre premiers :

94 & 0x0f //   0101 1110 
          // & 0000 1111
          // -----------
          // = 0000 1110

Un élément important à prendre en compte est qu'avant l'exécution d'une opération de manipulation de bits, les primitifs de type byte, short et char sont promus en int (lors d'une opération de décalage de bits une promotion unaire est effectuée et lors d'une opération logique bit à bit une promotion binaire). De fait, bien que les opérations représentées en commentaire ne comptent que 8 bits, il y en a 32 en réalité. 94 étant positif, cela n'a pas d'importance.

De plus, dans les deux exemples précédents, les deux opérandes de chaque opération étant des valeurs littérales il est possible d'assigner le résultat à une variable de type byte. Néanmoins, si l'un des opérandes est une variable il est obligatoire d'effectuer explicitement un downcast ; et il en est de même dans certains cas d'utilisation de valeurs littérales. La priorité du compilateur est d'éviter - autant que possible - tout overflow ou perte d'information.

Implémentons à présent notre méthode :

public byte[] byteToHex0(byte number) {
    final byte[] bytes = new byte[2];
    bytes[0] = (byte)(number >> 4);
    bytes[1] = (byte)(number & 0x0f);
    return bytes;
}

Source

Si vous lancez le test unitaire, il devrait se terminer en succès.

$ ant test -DtestClass=org.isk.jvmhardcore.mystery.ByteToHexTest -DtestMethod=byteToHex0Test

Il est temps à présent de se demander si notre test est complet ! Y a-t-il des cas que nous n'avons pas testés ?

Bien évidemment, si je pose la question, la réponse est non. En Java, un byte représente un nombre signé. Il nous faut donc tester une valeur négative.

Il est important de noter qu'en bytecode toutes les valeurs sont positives, or en utilisant la méthode statique byte[] java.nio.Files.readAllBytes() chaque octet est placé dans une variable de type byte. Par conséquent, les valeurs supérieures à 127 sont représentées sous la forme de nombres négatifs (cf. Complément à deux).

Prenons par exemple le nombre -23 et écrivons un nouveau test :

@Test
public void byteToHex1Test() {
    // -23(10) = E9(16) = 1110 1001 = 233(10)
    final byte number = -23;
    final byte[] hex = byteToHex0(number);
 
    Assert.assertArrayEquals(new byte[]{14, 9}, hex);

Source

À présent le test unitaire est en échec, comme le confirme le test suivant (Source) :

$ ant test -DtestClass=org.isk.ByteToHexTest -DtestMethod=byteToHex1Test

Reprenons donc notre méthode byteToHex0(). La méthode fait quatre lignes ; la première et la dernière ne font pas grand-chose. Par conséquent, le problème doit venir de l'une des deux autres, voire les deux.

Commençons par la première :

-23 >> 4 // 1111 1111 1111 1111 1111 1111 1110 1001 >> 4
         // = 1111 1111 1111 1111 1111 1111 1110

ce qui n'est absolument pas ce que nous souhaitons.

Note : l'opérateur >> décale de x positions des bits en dupliquant le MSB (Most Significant Bit, le bit le plus à gauche). -23 étant négatif, son MSB est égal à 1, ce qui explique que ce sont des 1 qui ont été ajoutés et non des 0.

En Java, nous avons aussi l'opérateur >>> qui décale de x positions les bits d'un nombre considéré comme non signé.

-23 >>> 4 // 1111 1111 1111 1111 1111 1111 1110 1001 >>> 4
          // = 0000 1111 1111 1111 1111 1111 1110

Malheureusement - une fois de plus -, ce n'est pas le résultat escompté.

Il nous faut donc supprimer le signe avant de décaler les bits. Nous allons utiliser à nouveau un masque :

-23 & 0xff //   1111 1111 1111 1111 1111 1111 1110 1001 
           // & 0000 0000 0000 0000 0000 0000 1111 1111 
           // -----------------------------------------
           // = 0000 0000 0000 0000 0000 0000 1110 1001

À présent en utilisant le nombre non signé (233) et l'opérateur >>> (ou >>) nous obtiendrons le bon résultat.

byte[] byteToHex1(byte number) {
    final int unsignedByte = number & 0xff;
    final byte[] bytes = new byte[2];
    bytes[0] = (byte)(unsignedByte >>> 4);
    bytes[1] = (byte)(unsignedByte & 0x0f);
    return bytes;
}

Source

$ ant test -DtestClass=org.isk.ByteToHexTest -DtestMethod=byteToHex2Test

Ceci conclut le départ de notre fabuleux voyage dans le monde de la JVM. J'espère que vous prendrez autant de plaisir à lire ces parties que moi à les écrire.

Et bien sûr toutes critiques constructives sont les bienvenues.