Discussion :

[Faiche]

Bonjour,

Lors d'un entretien, je suis tombé sur une question à laquelle je n'avais pas le début d'une réponse.

Soit la classe suivante (de mémoire) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
public class Machin
{
   { system.out.println("1"); }
 
   static
   {
      system.out.println("2");
   }
 
   public Machin()
   {
     system.out.println("3");
   }
 
   public static void main()
   {
     system.out.println("4");
     Machin m = new Machin();
   }
}

Quel est l'ordre d'impression ?

J'ai répondu (je crois) : 2 4 1 3

Mais c'était au hazard. Une bonne âme connaitrait-elle les règles permettant de déterminer cet ordre à coup sur ?


ps : pourquoi utiliser, et dans quel cas, un bloc qui sort de nulle part, comme le bloc 1 ?


Merci

[CheryBen]

2, 4, 1, 3 est la bonne réponse

Ce qui est static est exécuté au chargement de la classe.

Le bloc "1" est exécuté avant chaque instanciation de la classe. Du moins j'avais fait des tests et j'en ai conclu ce comportement, il n'apparaît jamais dans les cours/tutoriels. Je l'ai uniquement vu dans le livre de préparation SCJP. Je ne sais pas si il est vraiment utile car il suffit de mettre ce code dans le constructeur et cela revient au même.

ps : il manque un static devant void main()

[Furikawari]

j'ai 4 2 1 3 (jdk1.6), j'avais juste un doute sur le 1.

Perso ça me navre que des recruteurs posent ce genre de questions...

[Furikawari]

Une remarque en passant sur l'affichage du static : ça dépend de la JVM.

Dans la spec Java il est dit qu'une classe doit être chargée avant sa première utilisation. Rien ne dit, par exemple, qu'elle doit être chargée au moment d'entrer dans la fonction où se fait cette initialisation, etc. Et visiblement c'est le cas dans ma config.

[Faiche]

Merci pour les réponses. Même si le résultat peut être contestable pour le 2 et le 4, au moins je connais maintenant le mécanisme derrière ce code.

Pour le test, je trouve ne trouve pas ça malin non plus, car si jamais je vois un de mes développeurs pondre un truc pareil (je pense au 1), je le met au coin.

Donc plutôt que de vérifier si le futur employé connait toutes les techniques pour faire du code illisible, j'aurai tendance à le laisser dans l'ignorance sur certains points, et insister sur le code propre.