Accessibilité classe interne à une méthode

Bonjour,

Voici le petit bout de code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

public class InnerMethod {   private int x = 10;   public void test() { class LocalClass { private int x = 3;   private void printX() { System.out.println(InnerMethod.this.x + this.x); } }   LocalClass l = new LocalClass(); l.printX(); }   public static void main(String[] args) { InnerMethod monInnerMethod = new InnerMethod(); monInnerMethod.test(); }   }

---

Lorsque je lance ce programme, j'obtiens le résultat attendu : 13.

Cependant je n'arrive pas à comprendre pourquoi j'ai le droit d'appeler l'instruction l.printX() étant donné que cette méthode est déclarée private au sein de la classe LocalClass.

Ne devrais-je pas pouvoir l'appeler uniquement au sein de la classe LocalClass ??

Alors déjà, remarquons qu'on peut trouver un exemple plus simple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

public class InnerMethod {   private int x = 10;   private class InnerClass { private int x = 3;   private void printX() { System.out.println(InnerMethod.this.x + this.x); } }     public void test() { InnerClass i = new InnerClass(); i.printX(); }   public static void main(String[] args) { InnerMethod monInnerMethod = new InnerMethod(); monInnerMethod.test(); }   }

---

Parce que bon, les classes locales, c'est pas ce qu'on utilise le plus souvent, ce qui est normal vu que ça ne sert pas à grand-chose.

Mais bon, donc, dans les classes internes : même raisonnement, même résultat. En fait, c'est le cas avec toutes les classes imbriquées. Pourquoi ?

Eh bien on dit souvent que private restreint l'accès à la classe en cours, parce que c'est simple et que c'est l'idée de la chose.
Mais en réalité c'est plus compliqué.

Définition de l'accès private dans les JLS.

En fait, private restreint l'accès non pas à la classe en cours, mais à la top-level class en cours.
Une top-level class est une classe qui n'est imbriquée dans aucune autre : elle n'est pas déclarée entre les accolades d'une autre classe.

Tout dans une classe a donc accès à tout ce qu'elle contient, même à ce qui est private dans une de ses classes imbriquées. Et même ses autres classes imbriquées ont cet accès absolu les unes aux autres.

On peut donc en déduire, que, pour les classes private (qui ne sont accessibles qu'à la top-level class en cours) et pour les classes locales (qui ne sont accessibles qu'à la méthode en cours,) ça ne sert à rien de donner des droits d'accès à ce qu'elles contiennent.
Parce que tout ce qui a accès à ces classes, a aussi accès à tout leur contenu, quel que soit le droit d'accès indiqué.

ok merci pour cette réponse très claire !

Salut,

Citation:

---

Envoyé par thelvin

Tout dans une classe a donc accès à tout ce qu'elle contient, même à ce qui est private dans une de ses classes imbriquées. Et même ses autres classes imbriquées ont cet accès absolu les unes aux autres.

---

Juste pour compléter la réponse de thelvin : ce mécanisme d'accès au private est propre au langage Java mais il n'existe pas au niveau du bytecode de la JVM.

En fait il est simuler via la génération implicite d'une méthode d'accès par le compilateur. On peut repérer ces méthodes via la reflection et le marqueur "synthetic" :

Code:

---

1 2 3

for (Method method : LocalClass.class.getDeclaredMethods()) { System.out.println(method + " / " + method.isSynthetic()); }

---

Ce qui donne dans notre cas :

Code:

---

1 2	static void InnerMethod$1LocalClass.access$0(InnerMethod$1LocalClass) / true private void InnerMethod$1LocalClass.printX() / false

---

La méthode access$0() est généré par le compilateur avec une visibilité "package", et permet l'appel à la méthode private. Elle doit ressembler à quelque chose comme cela :

Code:

---

1 2 3

static void access$0(LocalClass thiz) { thiz.printX(); }

---

Le compilateur remplacera alors l'appel "l.printX()" par l'appel de cette méthode static...



Bref : autant éviter les méthodes private dans ces cas là ;)


a++

Ah, je me disais bien qu'il y avait un truc que je comprenais pas, mais je voulais pas entrer dans les arcanes du bytecode.

Merci pour la précision.