Discussion :

[Deaf]

Bonjour,

je suis tombé sur un problème surprenant lié au chargement des classes et/ou peut-être à la compilation.

Pour le reproduire, voici la marche à suivre:

• Créer une classe ToDelete (vide)
• Créer une classe LoadedClass contenant la méthode ci-dessous (copiez exactement le code, cf. PS en fin de message)
• Créer un main qui se contente d'appeler le constructeur de LoadedClass (constructeur par défaut)
• Lancer le main sans mettre la classe ToDelete dans le classpath

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
    public void method()
    {
        boolean flag = false; // Peut valoir true...
 
        if (flag)
        {
            final ToDelete obj1 = new ToDelete();
        }
        else
        {
            final Object obj2 = new Object();
        }
    }

Là, se produit un joli NoClassDefFoundError sur la classe ToDelete.
Or, la méthode utilisant (parfois) cette classe n'a pas été appelée.

Savez-vous à quoi cela est-il dû?

PS: Pour vous convaincre que cela n'est pas normal, il suffit de modifier légèrement le code de la méthode et de voir qu'une erreur n'est levée. Le code fournit semble très sensible.
Par exemple, vous pouvez:

• supprimer le flag est mettre directement true ou false dans le if
• supprimer le else
• enlever la structure if et conserver les deux affectations
• etc.

[wax78]

Donne un peu tout le code ?

(Sinon j'imagine qu'il y'a un import de la dite classe todelete et meme si tu t'en serts pas et qu'il ne la trouve pas -> classnotfound)

[Mathieu.J]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Savez-vous à quoi cela est-il dû?

Je dirait que selon les optimisation du compilateur, lors du chargement de ta classe LoadedClass il peut être demandé le pré-chargement de la classe ToDelete.

[Deaf]

Donne un peu tout le code ?

Tout le code est là, j'ai réduit mon code de reproduction au code fourni.

La classe LoadedClass ne contient aucun champ, hérite d'Object et ne possède que la méthode du premier post.

La classe ToDelete est vide.

Le main fait juste:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new LoadedClass()

.

(Sinon j'imagine qu'il y'a un import de la dite classe todelete et meme si tu t'en serts pas et qu'il ne la trouve pas -> classnotfound)

Les imports n'existent plus une fois les classes compilées.
De plus, les classes peuvent être dans des packages différents ou identiques, cela ne change rien.

[wax78]

Et bien nous sommes au delà de mes compétences dans ce cas

[thelvin]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Savez-vous à quoi cela est-il dû?

Je dirait que selon les optimisation du compilateur, lors du chargement de ta classe LoadedClass il peut être demandé le pré-chargement de la classe ToDelete.

En fait les règles sont précises. Mais méconnues. Dans le cas présent les optimisations du compilateur ne varient pas, il doit les faire, selon les JLS.

En l'occurrence, la classe ToDelete est littéralement utilisée dans la méthode method(), dont on ne sait pas où et quand elle peut être appelée.
Il est donc nécessaire de charger, préventivement, cette classe, pour être prêt quand la méthode sera appelée.

À noter que ce n'est pas le cas en mettant if(false).
La raison en est que false est une expression constante et que tout ce qui s'y trouve est reconnu comme code mort. Il y a deux niveaux de code morts gérés :
- les plus évidents, qui ne compilent même pas (exemple : instructions après le return.)
- ceux qui le sont moins, qui compilent mais comme vides. (exemple : code dans une branche conditionnelle, qui ne dépend que d'expressions constantes, et donc dont on connaît à la compilation quelle branche est parcourue. À noter qu'une expression constante peut venir d'autres classes, et donc que changer une autre classe peut changer l'effet. Ce serait gênant qu'une erreur de compilation arrive dans ce cas.)

EDIT : sauf que tout ça n'a rien à voir avec le problème exposé. My bad -_-°.

[Deaf]

Il est donc nécessaire de charger, préventivement, cette classe, pour être prêt quand la méthode sera appelée.

Je n'ai jamais observé ce comportement (à part dans ce cas très précis). N'ayant pas lu les JLS, je ne peux pas dire que c'est normal, mais j'ai toujours vu la JVM charger les classes au moment où elle en a besoin (exécution de l'instruction) et pas au chargement de la classe.

En ce qui concerne le code mort, cela n'entre pas en ligne de compte car en changeant le flag, le résultat est le même. De plus, à l'origine, ce n'était pas un booléen, mais un test d'existence de fichier, imprévisible à la compile.

Pour s'en convaincre, il suffit de sortir le flag pour le même en champ de la classe, avec un setter. Ainsi, le compilateur ne pourra pas prévoir non plus la valeur du flag.

[thelvin]

D'accord, je me suis trompé de problème : en effet si le main() se contente d'appeler le constructeur, en principe il n'y a pas de raison de prévoir l'appel de method().

Sur ce point-là, je ne sais pas ce que disent les JLS, mais ça a l'air de varier.