Qu'affiche ce code ?

class Super {
    static { System.out.print("**Super** "); }
}
 
class Un {
    static { System.out.print("**Un** "); }
}
 
class Deux extends Super {
    static { System.out.print("**Deux** "); }
 
    static final String DEUX = "dEuX";
}
 
class TestClasse {
    public static void main(String[] args) throws Exception {
        Un          o = null;
        Class<Deux> c = Deux.class;
 
        System.out.println(Deux.DEUX);
        System.out.println(((Object) o == (Object) c));
        System.out.println(c.equals(o));
        System.out.println(c);     // Appelle toString() sur c.
        System.out.println(c.newInstance());
    }
}

Réponse (avec la JVM Sun 1.5, ou la JVM IBM de même niveau) :

dEuX
false
false
class Deux
**Super** **Deux** Deux@82ba41

L'analyse de ce résultat montre que les blocs d'initialisation statique de Super et Deux ne sont exécutés que lorsqu'une instance de Deux est créée, et pas avant. Quant au bloc d'initialisation statique de Un, il n'est tout simplement jamais exécuté. Étonnant, non ?

Conclusion : utiliser un littéral classe (ici Deux.class) ne provoque pas le chargement de la classe associée. Et déclarer une variable du type de cette classe non plus. Plus fort : manipuler l'instance de Class représentant cette classe, et appeler des opérations sur cette instance (y compris les opérations d'introspection), ne provoquent toujours pas le chargement de la classe.

En fait, comme l'indique clairement la spécification Java (JLS), seules l'une des 5 situations suivantes garantissent le chargement d'une classe T, si celle-ci ne l'est pas encore :

• une instance de T est créée.
• une méthode statique de T est invoquée.
• une valeur est affectée à un attribut statique de T.
• la valeur d'un attribut statique non constant de T est utilisée (cf. JLS 4.12.4).
• T est une classe de niveau fichier, et une instruction assert (cf. JLS 14.10), situé à l'intérieur de son code, est exécutée.

Aucun autre cas ne le garantit.

Notez que ce comportement "paresseux" a été introduit avec la JVM 1.5. Auparavant, certaines opérations, comme la déclaration d'une référence sur une classe provoquait son chargement. Ainsi, le code du quiz donne le résultat suivant avec la JVM Sun 1.4.2 (il faut bien sûr apporter une toute petite modification au code du quiz, que je vous laisse trouver) :

**Super** **Deux** dEuX
false
false
class Deux
Deux@1ac04e8

Cette petite modification de comportement peut être la cause de bugs assez subtils lors de la migration vers une JVM 1.5+.
Par exemple, nombre de développeurs ont eu besoin des énumérations avant l'introduction des Enum dans Java5, et ont donc utilisé les Enums de la librairie commons.lang. Or, cette implémentation repose sur des Map<Class, Entry> ; les constantes énumérées ne sont donc référencées qu'indirectement, et leurs classes ne sont pas chargées sur les JVM 1.5+. Résultat : la comparaison de ces Enums renvoie toujours false...
Il n'y a malheureusement aucune solution "propre" à ce problème, à part migrer vers les Enumss natifs de Java 5+.