Penser en Java

Quand deux méthodes ont le même nom, comment Java peut-il décider quelle méthode est demandée ? Il y a une règle toute simple : chaque méthode surchargée doit prendre une liste unique de types de paramètres.

Lorsqu'on y pense, cela paraît tout à fait sensé : comment le développeur lui-même pourrait-il choisir entre deux méthodes du même nom, autrement que par le type des paramètres ?

Une différence dans l'ordre des paramètres est suffisante pour distinguer deux méthodes (cette approche n'est généralement pas utilisée, car elle donne du code difficile à maintenir) :

//: c04:OverloadingOrder.java
// Surcharge basée sur l'ordre
// des paramètres.

public class OverloadingOrder {
  static void print(String s, int i) {
    System.out.println(
      "String: " + s +
      ", int: " + i);
  }
  static void print(int i, String s) {
    System.out.println(
      "int: " + i +
      ", String: " + s);
  }
  public static void main(String[] args) {
    print("String first", 11);
    print(99, "Int first");
  }
} ///:~

Les deux méthodes print( ) ont les mêmes paramètres, mais dans un ordre différent, et c'est ce qui les différencie.

Un type de base peut être promu automatiquement depuis un type plus petit vers un plus grand ; ceci peut devenir déconcertant dans certains cas de surcharge. L'exemple suivant montre ce qui se passe lorsqu'un type de base est passé à une méthode surchargée :

//: c04:PrimitiveOverloading.java
// Promotion des types de base et surcharge.

public class PrimitiveOverloading {
  // boolean ne peut pas être converti automatiquement
  static void prt(String s) { 
    System.out.println(s); 
  }

  void f1(char x) { prt("f1(char)"); }
  void f1(byte x) { prt("f1(byte)"); }
  void f1(short x) { prt("f1(short)"); }
  void f1(int x) { prt("f1(int)"); }
  void f1(long x) { prt("f1(long)"); }
  void f1(float x) { prt("f1(float)"); }
  void f1(double x) { prt("f1(double)"); }

  void f2(byte x) { prt("f2(byte)"); }
  void f2(short x) { prt("f2(short)"); }
  void f2(int x) { prt("f2(int)"); }
  void f2(long x) { prt("f2(long)"); }
  void f2(float x) { prt("f2(float)"); }
  void f2(double x) { prt("f2(double)"); }

  void f3(short x) { prt("f3(short)"); }
  void f3(int x) { prt("f3(int)"); }
  void f3(long x) { prt("f3(long)"); }
  void f3(float x) { prt("f3(float)"); }
  void f3(double x) { prt("f3(double)"); }

  void f4(int x) { prt("f4(int)"); }
  void f4(long x) { prt("f4(long)"); }
  void f4(float x) { prt("f4(float)"); }
  void f4(double x) { prt("f4(double)"); }

  void f5(long x) { prt("f5(long)"); }
  void f5(float x) { prt("f5(float)"); }
  void f5(double x) { prt("f5(double)"); }

  void f6(float x) { prt("f6(float)"); }
  void f6(double x) { prt("f6(double)"); }

  void f7(double x) { prt("f7(double)"); }

  void testConstVal() {
    prt("Testing with 5");
    f1(5);f2(5);f3(5);f4(5);f5(5);f6(5);f7(5);
  }
  void testChar() {
    char x = 'x';
    prt("char argument:");
    f1(x);f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);
  }
  void testByte() {
    byte x = 0;
    prt("byte argument:");
    f1(x);f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);
  }
  void testShort() {
    short x = 0;
    prt("short argument:");
    f1(x);f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);
  }
  void testInt() {
    int x = 0;
    prt("int argument:");
    f1(x);f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);
  }
  void testLong() {
    long x = 0;
    prt("long argument:");
    f1(x);f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);
  }
  void testFloat() {
    float x = 0;
    prt("float argument:");
    f1(x);f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);
  }
  void testDouble() {
    double x = 0;
    prt("double argument:");
    f1(x);f2(x);f3(x);f4(x);f5(x);f6(x);f7(x);
  }
  public static void main(String[] args) {
    PrimitiveOverloading p = 
      new PrimitiveOverloading();
    p.testConstVal();
    p.testChar();
    p.testByte();
    p.testShort();
    p.testInt();
    p.testLong();
    p.testFloat();
    p.testDouble();
  }
} ///:~

En regardant la sortie du programme, on voit que la constante 5 est considérée comme un int. Lorsqu'une méthode surchargée utilisant un int est disponible, elle est utilisée. Dans tous les autres cas, si un type de données est plus petit que l'argument de la méthode, le type est promu. char est légèrement différent, comme il ne trouve pas une correspondance exacte, il est promu vers un int.

//: c04:Demotion.java
// Types de base déchus et surcharge.

public class Demotion {
  static void prt(String s) { 
    System.out.println(s); 
  }

  void f1(char x) { prt("f1(char)"); }
  void f1(byte x) { prt("f1(byte)"); }
  void f1(short x) { prt("f1(short)"); }
  void f1(int x) { prt("f1(int)"); }
  void f1(long x) { prt("f1(long)"); }
  void f1(float x) { prt("f1(float)"); }
  void f1(double x) { prt("f1(double)"); }

  void f2(char x) { prt("f2(char)"); }
  void f2(byte x) { prt("f2(byte)"); }
  void f2(short x) { prt("f2(short)"); }
  void f2(int x) { prt("f2(int)"); }
  void f2(long x) { prt("f2(long)"); }
  void f2(float x) { prt("f2(float)"); }

  void f3(char x) { prt("f3(char)"); }
  void f3(byte x) { prt("f3(byte)"); }
  void f3(short x) { prt("f3(short)"); }
  void f3(int x) { prt("f3(int)"); }
  void f3(long x) { prt("f3(long)"); }

  void f4(char x) { prt("f4(char)"); }
  void f4(byte x) { prt("f4(byte)"); }
  void f4(short x) { prt("f4(short)"); }
  void f4(int x) { prt("f4(int)"); }

  void f5(char x) { prt("f5(char)"); }
  void f5(byte x) { prt("f5(byte)"); }
  void f5(short x) { prt("f5(short)"); }

  void f6(char x) { prt("f6(char)"); }
  void f6(byte x) { prt("f6(byte)"); }

  void f7(char x) { prt("f7(char)"); }

  void testDouble() {
    double x = 0;
    prt("double argument:");
    f1(x);f2((float)x);f3((long)x);f4((int)x);
    f5((short)x);f6((byte)x);f7((char)x);
  }
  public static void main(String[] args) {
    Demotion p = new Demotion();
    p.testDouble();
  }
} ///:~

Ici, les méthodes prennent des types de base plus restreints. Si les paramètres sont d'un type plus grand, if faut les caster (convertir) vers le type requis en utilisant le nom du type entre parenthèses. Sinon, le compilateur donnera un message d'erreur.

Il est important de noter qu'il s'agit d'une conversion vers un type plus petit, ce qui signifie que des informations peuvent être perdues pendant la conversion. C'est d'ailleurs pour cette raison que le compilateur force une conversion explicite.

Il est fréquent de se demander « Pourquoi seulement les noms de classes et la liste des paramètres des méthodes ? Pourquoi ne pas aussi distinguer entre deux méthodes en se basant sur leur type de retour ? » Par exemple, ces deux méthodes, qui ont le même nom et les mêmes arguments, peuvent facilement être distinguées l'une de l'autre :

void f() {}
int f() {}

Cela fonctionne bien lorsque le compilateur peut déterminer le sens sans équivoque depuis le contexte, comme dans int x = f( ). Par contre, on peut utiliser une méthode et ignorer sa valeur de retour. On se réfère souvent à cette action comme appeler une méthode pour ses effets de bord puisqu'on ne s'intéresse pas à la valeur de retour, mais aux autres effets que cet appel de méthode génère. Donc, si on appelle la méthode comme suit :

f();

Comment Java peut-il déterminer quelle méthode f( ) doit être exécutée ? Et comment quelqu'un lisant ce code pourrait-il le savoir ? À cause de ce genre de difficultés, il est impossible d'utiliser la valeur de retour pour différencier deux méthodes Java surchargées.

Comme mentionné précédemment, un constructeur par défaut (c.à.d un constructeur « no-arg » ) est un constructeur sans argument, utilisé pour créer des « objets de base ». Si une classe est créée sans constructeur, le compilateur créé automatiquement un constructeur par défaut. Par exemple :

//: c04:DefaultConstructor.java

class Bird {
  int i;
}

public class DefaultConstructor {
  public static void main(String[] args) {
    Bird nc = new Bird(); // défaut !
  }
} ///:~

La ligne

new Bird();

crée un nouvel objet et appelle le constructeur par défaut, même s'il n'était pas défini explicitement. Sans lui, il n'y aurait pas de méthode à appeler pour créer cet objet. Par contre, si au moins un constructeur est défini (avec ou sans argument), le compilateur n'en synthétisera pas un :

class Bush {
  Bush(int i) {}
  Bush(double d) {}
}

Maintenant si on écrit :

new Bush();

le compilateur donnera une erreur indiquant qu'aucun constructeur ne correspond. C'est comme si lorsqu'aucun constructeur n'est fourni, le compilateur dit « Il faut un constructeur, je vais en créer un ». Alors que s'il existe un constructeur, le compilateur dit « Il y a un constructeur donc le développeur sait se qu'il fait ; s'il n'a pas défini de constructeur par défaut c'est qu'il ne désirait pas qu'il y en ait un »

Lorsqu'il existe deux objets a et b du même type, il est intéressant de se demander comment on peut appeler une méthode f( ) sur ces deux objets :

class Banana { void f(int i) { /* ... */ } }
Banana a = new Banana(), b = new Banana();
a.f(1);
b.f(2);

S'il y a une unique méthode f( ), comment cette méthode peut-elle savoir si elle a été appelée sur l'objet a ou b ?

Pour permettre au développeur d'écrire le code dans une syntaxe pratique et orienté objet dans laquelle on « envoie un message vers un objet », le compilateur effectue un travail secret pour le développeur. Il y a un premier paramètre caché passé à la méthode f( ), et ce paramètre est une référence vers l'objet en train d'être manipulé. Les deux appels de méthode précédents correspondent donc à ceci :

Banana.f(a,1);
Banana.f(b,2);

Ce travail est interne et il est impossible d'écrire des expressions de ce type directement en espérant que le compilateur les acceptera, mais cela donne une idée de ce qui se passe.

Supposons maintenant que l'on est à l'intérieur d'une méthode et que l'on désire obtenir une référence sur l'objet courant. Comme cette référence est passée en tant que paramètre caché par le compilateur, il n'y a pas d'identificateur pour elle. C'est pour cette raison que le mot-clef this existe. this , qui ne peut être utilisé qu'à l'intérieur d'une méthode - est une référence sur l'objet pour lequel cette méthode a été appelée. On peut utiliser cette référence comme toute autre référence vers un objet. Il n'est toutefois pas nécessaire d'utiliser this pour appeler une méthode de la classe courante depuis une autre méthode de la classe courante ; il suffit d'appeler cette méthode. La référence this est automatiquement utilisée pour l'autre méthode. On peut écrire :

class Apricot {
  void pick() { /* ... */ }
  void pit() { pick(); /* ... */ }
}

À l'intérieur de pit( ), on pourrait écrire this.pick( ), mais ce n'est pas nécessaire. Le compilateur le fait automatiquement pour le développeur. Le mot-clef this est uniquement utilisé pour les cas spéciaux dans lesquels on doit utiliser explicitement une référence sur l'objet courant. Par exemple, il est couramment utilisé en association avec return quand on désire renvoyer une référence sur l'objet courant :

//: c04:Leaf.java
// Utilisation simple du mot-clef "this".

public class Leaf {
  int i = 0;
  Leaf increment() {
    i++;
    return this;
  }
  void print() {
    System.out.println("i = " + i);
  }
  public static void main(String[] args) {
    Leaf x = new Leaf();
    x.increment().increment().increment().print();
  }
} ///:~

Puisque increment( ) renvoie une référence vers l'objet courant par le biais du mot-clef this, on peut facilement appeler plusieurs opérations successivement sur le même objet.

VI-B-5-a. Appeler un constructeur depuis un autre constructeur▲

//: c04:Flower.java
// Appel de constructeurs avec "this."

public class Flower {
  int petalCount = 0;
  String s = new String("null");
  Flower(int petals) {
    petalCount = petals;
    // Constructeur avec un unique paramètre int
    System.out.println(
      "Constructor w/ int arg only, petalCount= "
      + petalCount);
  }
  Flower(String ss) {
    // Constructeur avec un unique paramètre String
    System.out.println(
      "Constructor w/ String arg only, s=" + ss);
    s = ss;
  }
  Flower(String s, int petals) {
    this(petals);
//!    this(s); // Impossible d'en appeler deux !
    this.s = s; // Autre usage de "this"
    System.out.println("String & int args");
  }

  // Constructeur par défaut
  Flower() {
    this("hi", 47);
    System.out.println(
      "default constructor (no args)");
  }
  void print() {
//!    this(11); // Pas à l'intérieur d'une méthode normale !
    System.out.println(
      "petalCount = " + petalCount + " s = "+ s);
  }
  public static void main(String[] args) {
    Flower x = new Flower();
    x.print();
  }
} ///:~

VI-B-5-b. La signification de static▲

À ce point, on peut croire qu'il ne faudrait pas utiliser finalize( ) comme méthode générale de nettoyage. À quoi sert-elle alors ?

Une troisième règle stipule : le ramasse-miettes ne s'occupe que de la mémoire.

C'est-à-dire que la seule raison d'exister du ramasse-miettes est de récupérer la mémoire que le programme n'utilise plus. Par conséquent, toute activité associée au ramasse-miettes, la méthode finalize( ) en particulier, doit se concentrer sur la mémoire et sa libération.

Est-ce que cela veut dire que si un objet contient d'autres objets, finalize( ) doit libérer ces objets explicitement ? La réponse est... non. Le ramasse-miettes prend soin de libérer tous les objets, quelle que soit la façon dont ils ont été créés. Il se trouve que l'on a uniquement besoin de finalize( ) dans des cas bien précis où un objet peut allouer de la mémoire sans créer un autre objet. Cependant vous devez vous dire que tout est objet en Java, donc comment est-ce possible ?

Il semblerait que finalize( ) ait été introduit parce qu'il est possible d'allouer de la mémoire à « la C » en utilisant un mécanisme autre que celui proposé normalement par Java. Cela arrive généralement avec des méthodes natives, qui sont une façon d'appeler du code non Java en Java (les méthodes natives sont expliquées en Appendice B). C et C++ sont les seuls langages actuellement supportés par les méthodes natives, mais comme elles peuvent appeler des routines écrites avec d'autres langages, il est en fait possible d'appeler n'importe quoi. Dans ce code non Java, on peut appeler des fonctions de la famille de malloc( ) en C pour allouer de la mémoire, et à moins qu'un appel à free( ) ne soit effectué cette mémoire ne sera pas libérée, provoquant une « fuite ». Bien entendu, free( ) est une fonction C et C++, ce qui veut dire qu'elle doit être appelée dans une méthode native dans le finalize( ) correspondant.

Pour nettoyer un objet, son utilisateur doit appeler une méthode de nettoyage au moment où celui-ci est nécessaire. Cela semble assez simple, mais se heurte au concept de destructeur de C++. En C++, tous les objets sont, ou plutôt devraient être, détruits. Si l'objet C++ est créé localement (c'est-à-dire sur la pile, ce qui n'est pas possible en Java), alors la destruction se produit à la fermeture de la portée dans laquelle l'objet a été créé. Si l'objet a été créé par new (comme en Java) le destructeur est appelé quand le programmeur appelle l'opérateur C++ delete (cet opérateur n'existe pas en Java). Si le programmeur C++ oublie d'appeler delete, le destructeur n'est jamais appelé et l'on obtient une fuite mémoire. De plus les membres de l'objet ne sont jamais nettoyés non plus. Ce genre de bogue peut être très difficile à repérer.

Contrairement à C++, Java ne permet pas de créer des objets locaux, new doit toujours être utilisé. Cependant Java n'a pas de « delete » pour libérer l'objet, car le ramasse-miettes se charge automatiquement de récupérer la mémoire. Donc d'un point de vue simplistique, on pourrait dire qu'à cause du ramasse-miettes, Java n'a pas de destructeur. Cependant à mesure que la lecture de ce livre progresse, on s'aperçoit que la présence d'un ramasse-miettes ne change ni le besoin ni l'utilité des destructeurs (de plus, finalize( ) ne devrait jamais être appelé directement, ce n'est donc pas une bonne solution pour ce problème). Si l'on a besoin d'effectuer des opérations de nettoyage autres que libérer la mémoire, il est toujours nécessaire d'appeler explicitement la méthode correspondante en Java, ce qui correspondra à un destructeur C++ sans être aussi pratique.

Une des utilisations possibles de finalize( ) est l'observation du ramasse-miettes. L'exemple suivant montre ce qui se passe et résume les descriptions précédentes du ramasse-miettes :

//: c04:Garbage.java
// Démonstration du ramasse-miettes
// et de la finalisation

class Chair {
  static boolean gcrun = false;
  static boolean f = false;
  static int created = 0;
  static int finalized = 0;
  int i;
  Chair() {
    i = ++created;
    if(created == 47) 
      System.out.println("Created 47");
  }
  public void finalize() {
    if(!gcrun) {
      // Premier appel de finalize() :
      gcrun = true;
      System.out.println(
        "Beginning to finalize after " +
        created + " Chairs have been created");
    }
    if(i == 47) {
      System.out.println(
        "Finalizing Chair #47, " +
        "Setting flag to stop Chair creation");
      f = true;
    }
    finalized++;
    if(finalized >= created)
      System.out.println(
        "All " + finalized + " finalized");
  }
}

public class Garbage {
  public static void main(String[] args) {
    // Tant que le flag n'a pas été levé,
    // construire des objets Chair et String:
    while(!Chair.f) {
      new Chair();
      new String("To take up space");
    }
    System.out.println(
      "After all Chairs have been created:\n" +
      "total created = " + Chair.created +
      ", total finalized = " + Chair.finalized);
    // Arguments optionnels pour forcer
    // la finalisation et l'exécution du ramasse-miettes :
    if(args.length > 0) {
      if(args[0].equals("gc") || 
         args[0].equals("all")) {
        System.out.println("gc():");
        System.gc();
      }
      if(args[0].equals("finalize") || 
         args[0].equals("all")) {
        System.out.println("runFinalization():");
        System.runFinalization();
      }
    }
    System.out.println("bye!");
  }
} ///:~

Le programme ci-dessus crée un grand nombre d'objets Chair et, à un certain point après que le ramasse-miettes a commencé à s'exécuter, le programme arrête de créer des Chairs. Comme le ramasse-miettes peut s'exécuter n'importe quand, on ne sait pas exactement à quel moment il se lance, il existe donc un flag appelé gcrun qui indique si le ramasse-miettes a commencé son exécution. Un deuxième flag f est le moyen pour Chair de prévenir la boucle main( ) qu'elle devrait arrêter de fabriquer des objets. On lève ces deux flags dans finalize( ), qui est appelé pendant l'exécution du ramasse-miettes.

Deux autres variables statiques, created et finalized, enregistrent le nombre d'objets Chair créés par rapport au nombre réclamé par le ramasse-miettes. Enfin, chaque objet Chair contient sa propre version (non statique) de l'int i pour savoir quel est son numéro. Quand l'objet Chair numéro 47 est réclamé, le flag est mis à true pour arrêter la création des objets Chair.

Tout ceci se passe dans le main( ), dans la boucle

while(!Chair.f) {
      new Chair();
      new String("To take up space");
    }

On peut se demander comment cette boucle va se terminer puisque rien dans la boucle ne change la valeur de Chair.f. Cependant, finalize( ) le fera au moment de la réclamation du numéro 47.

La création d'un objet String à chaque itération représente simplement de l'espace mémoire supplémentaire pour inciter le ramasse-miettes à s'exécuter, ce qu'il fera dès qu'il se sentira inquiet pour le montant de mémoire disponible.

À l'exécution du programme, l'utilisateur fournit une option sur la ligne de commande : « gc », « finalize », ou « all » . Le paramètre « gc » permet l'appel de la méthode System.gc( ) (pour forcer l'exécution du ramasse-miettes). « finalize » permet d'appeler System.runFinalization( ) ce qui, en théorie, fait que tout objet non finalisé soit finalisé. Enfin, « all » exécute les deux méthodes.

Le comportement de ce programme et celui de la version de la première édition de cet ouvrage montrent que la question du ramasse-miettes et de la finalisation a évolué et qu'une grosse part de cette évolution s'est passée en coulisse. En fait, il est possible que le comportement du programme soit tout à fait différent lorsque vous lirez ces lignes.

Si System.gc( ) est appelé, alors la finalisation concerne tous les objets. Ce n'était pas forcément le cas avec les implémentations précédentes du JDK bien que la documentation dise le contraire. De plus, il semble qu'appeler System.runFinalization( ) n'ait aucun effet.

Cependant, on voit que toutes les méthodes de finalisation sont exécutées seulement dans le cas où System.gc( ) est appelé après que tous les objets aient été créés et mis à l'écart. Si System.gc( ) n'est pas appelé, seulement certains objets seront finalisés. En Java 1.1, la méthode System.runFinalizersOnExit( ) fut introduite pour que les programmes puissent exécuter toutes les méthodes de finalisation lorsqu'ils se terminent, mais la conception était boguée et la méthode a été classée deprecated. C'est un indice supplémentaire qui montre que les concepteurs de Java ont eu de nombreux démêlés avec le problème du ramasse-miettes et de la finalisation. Il est à espérer que ces questions ont été réglées dans Java 2.

Le programme ci-dessus montre que les méthodes de finalisation sont toujours exécutées, mais seulement si le programmeur force lui-même l'appel. Si on ne force pas l'appel de System.gc( ), le résultat ressemblera à ceci :

Created 47
Beginning to finalize after 3486 Chairs have been created
Finalizing Chair #47, Setting flag to stop Chair creation
After all Chairs have been created:
total created = 3881, total finalized = 2684
bye!

Toutes les méthodes de finalisation ne sont donc pas appelées à la fin du programme. Ce n'est que quand System.gc( ) est appelé que tous les objets qui ne sont plus utilisés seront finalisés et détruits.

Il est important de se souvenir que ni le ramasse-miettes, ni la finalisation ne sont garantis. Si la machine virtuelle Java (JVM) ne risque pas de manquer de mémoire, elle ne perdra (légitimement) pas de temps à en récupérer grâce au ramasse-miettes.

En général, on ne peut pas compter sur un appel à finalize( ), et il est nécessaire de créer des fonctions spéciales de nettoyage et de les appeler explicitement. Il semblerait donc que finalize( ) ne soit utile que pour effectuer des tâches de nettoyage mémoire très spécifiques dont la plupart des programmeurs n'aura jamais besoin. Cependant, il existe une très intéressante utilisation de finalize( ) qui ne nécessite pas que son appel soit garanti. Il s'agit de la vérification de la death condition3Un terme créé par Bill Venners (www.artima.com) pendant le séminaire que lui et moi avons donné ensemble. d'un objet (état d'un objet à sa destruction).

Au moment où un objet n'est plus intéressant, c'est-à-dire lorsqu'il est prêt à être réclamé par le ramasse-miettes, cet objet doit être dans un état où sa mémoire peut être libérée sans problème. Par exemple, si l'objet représente un fichier ouvert, celui-ci doit être fermé par le programmeur avant que la mémoire prise par l'objet ne soit réclamée. Si certaines parties de cet objet n'ont pas été nettoyées comme il se doit, il s'agit d'un bogue du programme qui peut être très difficile à localiser. L'intérêt de finalize( ) est qu'il est possible de l'utiliser pour découvrir cet état de l'objet, même si cette méthode n'est pas toujours appelée. Si une des finalisations trouve le bogue, alors le problème est découvert et c'est ce qui compte vraiment après tout.

Voici un petit exemple pour montrer comment on peut l'utiliser :

//: c04:DeathCondition.java
// Comment utiliser finalize() pour détecter les objets qui
// n'ont pas été nettoyés correctement.

class Book {
  boolean checkedOut = false;
  Book(boolean checkOut) { 
    checkedOut = checkOut; 
  }
  void checkIn() {
    checkedOut = false;
  }
  public void finalize() {
    if(checkedOut)
      System.out.println("Error: checked out");
  }
}

public class DeathCondition {
  public static void main(String[] args) {
    Book novel = new Book(true);
    // Nettoyage correct :
    novel.checkIn();
    // Perd la référence et oublie le nettoyage :
    new Book(true);
    // Force l'exécution du ramasse-miettes et de la finalisation :
    System.gc();
  }
} ///:~

Ici, la «death condition» est le fait que tous les objets de type Book doivent être « rendus » (checked in) avant d'être récupérés par le ramasse-miettes, mais dans la fonction main( ) une erreur de programmation fait qu'un de ces livres n'est pas rendu. Sans finalize( ) pour vérifier la « death condition », cela pourrait s'avérer un bogue difficile à trouver.

Il est important de noter l'utilisation de System.gc( ) pour forcer l'exécution de la finalisation (en fait, il est utile de le faire pendant le développement du programme pour accélérer le débogage). Cependant même si System.gc() n'est pas appelé, il est très probable que le livre (Book) perdu soit découvert par plusieurs exécutions successives du programme (en supposant que suffisamment de mémoire soit allouée pour que le ramasse-miettes se déclenche).

Les utilisateurs de langages où l'allocation d'objets sur le tas coûte cher peuvent supposer que la façon qu'a Java de tout allouer sur le tas (à l'exception des types de base) coûte également cher. Cependant, il se trouve que l'utilisation d'un ramasse-miettes peut accélérer de manière importante la création d'objets. Ceci peut sembler un peu bizarre à première vue : la réclamation d'objets aurait un effet sur la création d'objets. Mais c'est comme ça que certaines JVM fonctionnent et cela veut dire qu'en Java, l'allocation d'objets sur le tas peut être presque aussi rapide que l'allocation sur la pile dans d'autres langages.

Un exemple serait de considérer le tas en C++ comme une pelouse où chaque objet prend et délimite son morceau de gazon. Cet espace peut être abandonné un peu plus tard et doit être réutilisé. Avec certaines JVM, le tas de Java est assez différent ; il ressemble plus à une chaîne de montage qui avancerait à chaque fois qu'un objet est alloué. Ce qui fait que l'allocation est remarquablement rapide. Le « pointeur du tas » progresse simplement dans l'espace vide, ce qui correspond donc à l'allocation sur la pile en C++ (il y a bien sûr une petite pénalité supplémentaire pour le fonctionnement interne, mais ce n'est pas comparable à la recherche de mémoire libre).

On peut remarquer que le tas n'est en fait pas vraiment une chaîne de montage, et s'il est traité de cette manière, la mémoire finira par avoir un taux de « paging » (utiliser toute la mémoire virtuelle incluant la partie sur disque dur) important (ce qui représente un gros problème de performance) et finira par manquer de mémoire. Le ramasse-miettes apporte la solution en s'interposant et, alors qu'il collecte les miettes (les objets inutilisables), il compacte tous les objets du tas. Ceci représente l'action de déplacer le « pointeur du tas » un peu plus vers le début et donc plus loin du « page fault » (interruption pour demander au système d'exploitation des pages de mémoire supplémentaires situées dans la partie de la mémoire virtuelle qui se trouve sur disque dur). Le ramasse-miettes réarrange tout pour permettre l'utilisation de ce modèle d'allocation très rapide et utilisant une sorte de « tas infini ».

Pour comprendre comment tout cela fonctionne, il serait bon de donner maintenant une meilleure description de la façon dont un ramasse-miettes fonctionne. Nous utiliserons l'acronyme GC (en anglais, un ramasse-miette est appelé Garbage Collector) dans les paragraphes suivants. Une technique de GC relativement simple, mais lente est le compteur de référence. L'idée est que chaque objet contient un compteur de référence et à chaque fois qu'une nouvelle référence sur un objet est créée le compteur est incrémenté. À chaque fois qu'une référence est hors de portée ou que la valeur null lui est assignée, le compteur de références est décrémenté. Par conséquent, la gestion des compteurs de références représente un coût faible, mais constant tout au long du programme. Le ramasse-miettes se déplace à travers toute la liste d'objets et quand il en trouve un avec un compteur à zéro, il libère la mémoire. L'inconvénient principal est que si des objets se référencent de façon circulaire, ils ne peuvent jamais avoir un compteur à zéro tout en étant inaccessibles. Pour localiser ces objets qui se référencent mutuellement, le ramasse-miettes doit faire un important travail supplémentaire. Les compteurs de références sont généralement utilisés pour expliquer les ramasses-miettes, mais ils ne semblent pas être utilisés dans les implémentations de la JVM.

D'autres techniques, plus performantes, n'utilisent pas de compteur de références. Elles sont plutôt basées sur l'idée que l'on est capable de remonter la chaîne de références de tout objet « non mort » (i.e encore en utilisation) jusqu'à une référence vivant sur la pile ou dans la zone statique. Cette chaîne peut très bien passer par plusieurs niveaux d'objets. Par conséquent, si l'on part de la pile et de la zone statique et que l'on trace toutes les références, on trouvera tous les objets encore en utilisation. Pour chaque référence que l'on trouve, il faut aller jusqu'à l'objet référencé et ensuite suivre toutes les références contenues dans cet objet, aller jusqu'aux objets référencés, etc. jusqu'à ce que l'on ait visité tous les objets que l'on peut atteindre depuis la référence sur la pile ou dans la zone statique. Chaque objet visité doit être encore vivant. Notez qu'il n'y a aucun problème avec les groupes qui s'autoréférencent : ils ne sont tout simplement pas trouvés et sont donc automatiquement morts.

Avec cette approche, la JVM utilise un ramasse-miettes adaptatif. Le sort des objets vivants trouvés dépend de la variante du ramasse-miettes utilisée à ce moment-là. Une de ces variantes est le stop-and-copy. L'idée est d'arrêter le programme dans un premier temps (ce n'est pas un ramasse-miettes qui s'exécute en arrière-plan). Puis, chaque objet vivant que l'on trouve est copié d'un tas à un autre, délaissant les objets morts. De plus, au moment où les objets sont copiés, ils sont rassemblés les uns à côté des autres, compactant de ce fait le nouveau tas (et permettant d'allouer de la mémoire en la récupérant à l'extrémité du tas comme cela a été expliqué auparavant).

Bien entendu, quand un objet est déplacé d'un endroit à un autre, toutes les références qui pointent (i.e. qui référencent) l'objet doivent être mises à jour. La référence qui part du tas ou de la zone statique vers l'objet peut être modifiée sur le champ, mais il y a d'autres références pointant sur cet objet qui seront trouvées « sur le chemin ». Elles seront corrigées dès qu'elles seront trouvées (on peut s'imaginer une table associant les anciennes adresses aux nouvelles).

Il existe deux problèmes qui rendent ces « ramasse-miettes par copie » inefficaces. Le premier est l'utilisation de deux tas et le déplacement des objets d'un tas à l'autre, utilisant ainsi deux fois plus de mémoire que nécessaire. Certaines JVM s'en sortent en allouant la mémoire par morceau et en copiant simplement les objets d'un morceau à un autre.

Le deuxième problème est la copie. Une fois que le programme atteint un état stable, il se peut qu'il ne génère pratiquement plus de miettes (i.e. d'objets morts). Malgré ça, le ramasse-miettes par copie va quand même copier toute la mémoire d'une zone à une autre, ce qui est du gaspillage pur et simple. Pour éviter cela, certaines JVM détectent que peu d'objets meurent et choisissent alors une autre technique (c'est la partie d'« adaptation »). Cette autre technique est appelée mark and sweep (NDT : littéralement marque et balaye), et c'est ce que les versions précédentes de la JVM de Sun utilisaient en permanence. En général, le « mark and sweep » est assez lent, mais quand on sait que l'on génère peu ou pas de miettes, la technique est rapide.

La technique de « mark and sweep » suit la même logique de partir de la pile et de la zone de mémoire statique et de suivre toutes les références pour trouver les objets encore en utilisation. Cependant, à chaque fois qu'un objet vivant est trouvé, il est marqué avec un flag, mais rien n'est encore collecté. C'est seulement lorsque la phase de « mark » est terminée que le « sweep » commence. Pendant ce balayage, les objets morts sont libérés. Aucune copie n'est effectuée, donc si le ramasse-miettes décide de compacter la mémoire, il le fait en réarrangeant les objets.

Le « stop-and-copy » correspond à l'idée que ce type de ramasse-miettes ne s'exécute pas en tâche de fond, le programme est en fait arrêté pendant l'exécution du ramasse-miettes. La littérature de Sun mentionne assez souvent le ramasse-miettes comme une tâche de fond de basse priorité, mais il se trouve que le ramasse-miettes n'a pas été implémenté de cette manière, tout au moins dans les premières versions de la JVM de Sun. Le ramasse-miettes était plutôt exécuté quand il restait peu de mémoire libre. De plus, le « mark-and-sweep » nécessite l'arrêt du programme.

Comme il a été dit précédemment, la JVM décrite ici alloue la mémoire par blocs. Si un gros objet est alloué, un bloc complet lui est réservé. Le « stop-and-copy » strictement appliqué nécessite la copie de chaque objet vivant du tas d'origine vers un nouveau tas avant de pouvoir libérer le vieux tas, ce qui se traduit par la manipulation de beaucoup de mémoire. Avec des blocs, le ramasse-miettes peut simplement utiliser les blocs vides (et/ou contenant uniquement des objets morts) pour y copier les objets. Chaque bloc possède un compteur de génération pour savoir s'il est « mort » (vide) ou non. Dans le cas normal, seuls les blocs créés depuis le ramasse-miettes sont compactés ; les compteurs de générations de tous les autres blocs sont mis à jour s'ils ont été référencés. Cela prend en compte le cas courant des nombreux objets ayant une durée de vie très courte. Régulièrement, un balayage complet est effectué, les gros objets ne sont toujours pas copiés (leurs compteurs de génération sont simplement mis à jour) et les blocs contenant des petits objets sont copiés et compactés. La JVM évalue constamment l'efficacité du ramasse-miettes et si cette technique devient une pénalité plutôt qu'un avantage, elle la change pour un « mark-and-sweep ». De même, la JVM évalue l'efficacité du mark-and-sweep et si le tas se fragmente, le stop-and-copy est réutilisé. C'est là où l'« adaptation » vient en place et finalement on peut utiliser ce terme anglophone à rallonge : « adaptive generational stop-and-copy mark-and-sweep » qui correspondrait à « adaptatif entre marque-et-balaye et stoppe-et-copie de façon générationnelle ».

Comment peut-on donner une valeur initiale à une variable ? Une manière directe de le faire est la simple affectation au moment de la définition de la variable dans la classe (note : il n'est pas possible de le faire en C++ bien que tous les débutants s'y essayent). Les définitions des champs de la classe Measurement sont modifiées ici pour fournir des valeurs initiales :

class Measurement {
  boolean b = true;
  char c = 'x';
  byte B = 47;
  short s = 0xff;
  int i = 999;
  long l = 1;
  float f = 3.14f;
  double d = 3.14159;
  //. . .

On peut initialiser des objets de type non primitif de la même manière. Si Depth (NDT : « profondeur ») est une classe, on peut ajouter une variable et l'initialiser de cette façon :

class Measurement {
  Depth o = new Depth();
  boolean b = true;
  // . . .

Si o ne reçoit pas de valeur initiale et que l'on essaye de l'utiliser malgré tout, on obtient une erreur à l'exécution appelée exception (explications au titre XII).

Il est même possible d'appeler une méthode pour fournir une valeur d'initialisation :

class CInit {
  int i = f();
  //...
}

Bien sûr cette méthode peut avoir des arguments, mais ceux-ci ne peuvent pas être d'autres membres non encore initialisés, de la classe. Par conséquent ce code est valide :

class CInit {
  int i = f();
  int j = g(i);
  //...
}

Mais pas celui-ci :

class CInit {
  int j = g(i);
  int i = f();
  //...
}

C'est un des endroits où le compilateur se plaint avec raison du forward referencing (référence à un objet déclaré plus loin dans le code), car il s'agit d'une question d'ordre d'initialisation et non pas de la façon dont le programme est compilé.

Cette approche par rapport à l'initialisation est très simple. Elle est également limitée dans le sens où chaque objet de type Measurement aura les mêmes valeurs d'initialisation. Quelquefois c'est exactement ce dont on a besoin, mais d'autres fois un peu plus de flexibilité serait nécessaire.

On peut utiliser le constructeur pour effectuer les initialisations. Cela apporte plus de flexibilité pour le programmeur, car il est possible d'appeler des méthodes et effectuer des actions à l'exécution pour déterminer les valeurs initiales. Cependant il y a une chose à se rappeler : cela ne remplace pas l'initialisation automatique qui est faite avant l'exécution du constructeur. Donc par exemple :

class Counter {
  int i;
  Counter() { i = 7; }
  // . . .

Dans ce cas, i sera d'abord initialisé à 0 puis à 7. C'est ce qui se passe pour tous les types primitifs et les références sur objet, même pour ceux qui ont été initialisés explicitement au moment de leur définition. Pour cette raison, le compilateur ne force pas l'utilisateur à initialiser les éléments dans le constructeur à un endroit donné ni avant leur utilisation : l'initialisation est toujours garantie(23).

VI-D-2-a. Ordre d'initialisation▲

//: c04:OrderOfInitialization.java
// Montre l'ordre d'initialisation.

// Quand le constructeur est appelé pour créer
// un objet Tag, un message s'affichera :
class Tag {
  Tag(int marker) {
    System.out.println("Tag(" + marker + ")");
  }
}

class Card {
  Tag t1 = new Tag(1); // Avant le constructeur
  Card() {
    // Montre que l'on est dans le constructeur :
    System.out.println("Card()");
    t3 = new Tag(33); // Réinitialisation de t3
  }
  Tag t2 = new Tag(2); // Après le constructeur
  void f() {
    System.out.println("f()");
  }
  Tag t3 = new Tag(3); // la fin
}

public class OrderOfInitialization {
  public static void main(String[] args) {
    Card t = new Card();
    t.f(); // Montre que la construction a été effectuée
  }
} ///:~

Tag(1)
Tag(2)
Tag(3)
Card()
Tag(33)
f()

VI-D-2-b. Initialisation de données statiques▲

//: c04:StaticInitialization.java
// Préciser des valeurs initiales dans une
// définition de classe.

class Bowl {
  Bowl(int marker) {
    System.out.println("Bowl(" + marker + ")");
  }
  void f(int marker) {
    System.out.println("f(" + marker + ")");
  }
}

class Table {
  static Bowl b1 = new Bowl(1);
  Table() {
    System.out.println("Table()");
    b2.f(1);
  }
  void f2(int marker) {
    System.out.println("f2(" + marker + ")");
  }
  static Bowl b2 = new Bowl(2);
}

class Cupboard {
  Bowl b3 = new Bowl(3);
  static Bowl b4 = new Bowl(4);
  Cupboard() {
    System.out.println("Cupboard()");
    b4.f(2);
  }
  void f3(int marker) {
    System.out.println("f3(" + marker + ")");
  }
  static Bowl b5 = new Bowl(5);
}

public class StaticInitialization {
  public static void main(String[] args) {
    System.out.println(
      "Creating new Cupboard() in main");
    new Cupboard();
    System.out.println(
      "Creating new Cupboard() in main");
    new Cupboard();
    t2.f2(1);
    t3.f3(1);
  }
  static Table t2 = new Table();
  static Cupboard t3 = new Cupboard();
} ///:~

Bowl(1)
Bowl(2)
Table()
f(1)
Bowl(4)
Bowl(5)
Bowl(3)
Cupboard()
f(2)
Creating new Cupboard() in main
Bowl(3)
Cupboard()
f(2)
Creating new Cupboard() in main
Bowl(3)
Cupboard()
f(2)
f2(1)
f3(1)

VI-D-2-c. Initialisation statique explicite▲

class Spoon {
  static int i;
  static {
    i = 47;
  }
  // . . .

//: c04:ExplicitStatic.java
// Initialisation statique explicite
// avec l'instruction "static".

class Cup {
  Cup(int marker) {
    System.out.println("Cup(" + marker + ")");
  }
  void f(int marker) {
    System.out.println("f(" + marker + ")");
  }
}

class Cups {
  static Cup c1;
  static Cup c2;
  static {
    c1 = new Cup(1);
    c2 = new Cup(2);
  }
  Cups() {
    System.out.println("Cups()");
  }
}

public class ExplicitStatic {
  public static void main(String[] args) {
    System.out.println("Inside main()");
    Cups.c1.f(99);  // (1)
  }
  // static Cups x = new Cups();  // (2)
  // static Cups y = new Cups();  // (2) 
} ///:~

VI-D-2-d. Initialisation d'instance non statique▲

//: c04:Mugs.java
// Java "Instance Initialization." (Initialisation d'instance de Java)

class Mug {
  Mug(int marker) {
    System.out.println("Mug(" + marker + ")");
  }
  void f(int marker) {
    System.out.println("f(" + marker + ")");
  }
}

public class Mugs {
  Mug c1;
  Mug c2;
  {
    c1 = new Mug(1);
    c2 = new Mug(2);
    System.out.println("c1 & c2 initialized");
  }
  Mugs() {
    System.out.println("Mugs()");
  }
  public static void main(String[] args) {
    System.out.println("Inside main()");
    Mugs x = new Mugs();
  }
} ///:~

{
    c1 = new Mug(1);
    c2 = new Mug(2);
    System.out.println("c1 & c2 initialized");
  }

Java permet de créer facilement des tableaux multidimensionnels :

//: c04:MultiDimArray.java
// Création de tableaux multidimensionnels.
import java.util.*;

public class MultiDimArray {
  static Random rand = new Random();
  static int pRand(int mod) {
    return Math.abs(rand.nextInt()) % mod + 1;
  }
  static void prt(String s) {
    System.out.println(s);
  }
  public static void main(String[] args) {
    int[][] a1 = {
      { 1, 2, 3, },
      { 4, 5, 6, },
    };
    for(int i = 0; i < a1.length; i++)
      for(int j = 0; j < a1[i].length; j++)
        prt("a1[" + i + "][" + j +
            "] = " + a1[i][j]);
    // tableau 3-D avec taille fixe :
    int[][][] a2 = new int[2][2][4];
    for(int i = 0; i < a2.length; i++)
      for(int j = 0; j < a2[i].length; j++)
        for(int k = 0; k < a2[i][j].length;
            k++)
          prt("a2[" + i + "][" +
              j + "][" + k +
              "] = " + a2[i][j][k]);
    // tableau 3-D avec vecteurs de taille variable :
    int[][][] a3 = new int[pRand(7)][][];
    for(int i = 0; i < a3.length; i++) {
      a3[i] = new int[pRand(5)][];
      for(int j = 0; j < a3[i].length; j++)
        a3[i][j] = new int[pRand(5)];
    }
    for(int i = 0; i < a3.length; i++)
      for(int j = 0; j < a3[i].length; j++)
        for(int k = 0; k < a3[i][j].length;
            k++)
          prt("a3[" + i + "][" +
              j + "][" + k +
              "] = " + a3[i][j][k]);
    // Tableau d'objets non primitifs :
    Integer[][] a4 = {
      { new Integer(1), new Integer(2)},
      { new Integer(3), new Integer(4)},
      { new Integer(5), new Integer(6)},
    };
    for(int i = 0; i < a4.length; i++)
      for(int j = 0; j < a4[i].length; j++)
        prt("a4[" + i + "][" + j +
            "] = " + a4[i][j]);
    Integer[][] a5;
    a5 = new Integer[3][];
    for(int i = 0; i < a5.length; i++) {
      a5[i] = new Integer[3];
      for(int j = 0; j < a5[i].length; j++)
        a5[i][j] = new Integer(i*j);
    }
    for(int i = 0; i < a5.length; i++)
      for(int j = 0; j < a5[i].length; j++)
        prt("a5[" + i + "][" + j +
            "] = " + a5[i][j]);
  }
} ///:~

Le code d'affichage utilise length ; de cette façon il ne force pas une taille de tableau fixe.

Le premier exemple montre un tableau multidimensionnel de type primitif. Chaque vecteur du tableau est délimité par des accolades :

int[][] a1 = {
      { 1, 2, 3, },
      { 4, 5, 6, },
    };

Chaque paire de crochets donne accès à la dimension suivante du tableau.

Le deuxième exemple montre un tableau à trois dimensions alloué par new. Ici le tableau entier est alloué en une seule fois :

int[][][] a2 = new int[2][2][4];

Par contre, le troisième exemple montre que les vecteurs dans les tableaux qui forment la matrice peuvent être de longueurs différentes :

int[][][] a3 = new int[pRand(7)][][];
    for(int i = 0; i < a3.length; i++) {
      a3[i] = new int[pRand(5)][];
      for(int j = 0; j < a3[i].length; j++)
        a3[i][j] = new int[pRand(5)];
    }

Le premier new crée un tableau avec une longueur aléatoire pour le premier élément et le reste de longueur indéterminée. Le deuxième new à l'intérieur de la boucle for remplit les éléments, mais laisse le troisième index indéterminé jusqu'au troisième new.

On peut voir à l'exécution que les valeurs des tableaux sont automatiquement initialisées à zéro si on ne leur donne pas explicitement de valeur initiale.

Les tableaux d'objets non primitifs fonctionnent exactement de la même manière, comme le montre le quatrième exemple, qui présente la possibilité d'utiliser new dans les accolades d'initialisation :

Integer[][] a4 = {
      { new Integer(1), new Integer(2)},
      { new Integer(3), new Integer(4)},
      { new Integer(5), new Integer(6)},
    };

Le cinquième exemple montre comment un tableau d'objets non primitifs peut être construit pièce par pièce :

Integer[][] a5;
    a5 = new Integer[3][];
    for(int i = 0; i < a5.length; i++) {
      a5[i] = new Integer[3];
      for(int j = 0; j < a5[i].length; j++)
        a5[i][j] = new Integer(i*j);
    }

L'expression i*j est là uniquement pour donner une valeur intéressante à l'Integer.