Considérez le cas suivant:
public class A {
public A() { b = new B(); }
B b;
protected class B { }
}
4 Réponses :
Vous devez utiliser
this.new B();
désolé, mais cela .New b (); donne le même avertissement et le même comportement.
@RATS: Cela ne fera aucune différence pour le problème en main. La qualification «cette» est implicite.
Les classes intérieures sont essentiellement un hack introduit dans Java 1.1. La JVM n'a réellement aucun concept de classe intérieure, et le compilateur doit donc le faire le faire. Le compilateur génère la classe B "à l'extérieur" de la classe A, mais dans le même package, puis ajoute des accesseurs / constructeurs synthétiques pour permettre à un accès à celui-ci.
Lorsque vous donnez un constructeur protégé B, un constructeur peut accéder à ce constructeur puisqu'il est dans le même paquet, sans avoir besoin d'un constructeur synthétique à ajouter.
Ok, je le vois. Pour moi, cela signifie que je vais éviter l'utilisation de classes intérieures comme dans l'exemple, cela ne peut que conduire à la confusion.
Je ne le laisserais pas te déranger. Cet avertissement de compilateur particulier n'est pas vraiment utile pour quiconque, les méthodes synthétiques sont utilisées tout le temps avec des classes intérieures et n'ont aucun impact significatif.
IMHO Les méthodes synthétiques étaient une addition inutile à la langue. Il suffit d'utiliser l'ensemble des packages des membres «Privé» (que le compilateur sous le capot de toute façon) était une solution satisfaisante.
@Carlosheuberger Je pense que ce n'est pas la "vérité entière", voir le répondre je viens de poster ...
L'accès de classe B et son constructeur ne doit pas nécessairement être identique. Vous pouvez avoir une classe intérieure privée avec un constructeur de package-Scope, et c'est ce que je fais habituellement.
Mais comment pouvez-vous avoir une instance package privée d'une classe bien privée?
Je sais que cette question a maintenant presque trois ans, mais je trouve qu'une partie de la question n'est toujours pas répondu:
et: signifie-t-il que la classe B n'est plus privée au moment de l'exécution?
Carlos Heubergers Commentaire sur Skaffmans Réponse Suggestions, classe
B est toujoursprivé pour d'autres classes de l'emballage.Il est probablement juste pour le langage de programmation Java, c'est-à-dire qu'il n'est pas possible de faire référence à la classe
B d'une autre classe. Au moins pas sans l'utilisation de la réflexion (avec laquelle les membres de la classe privée peuvent également être consultés de l'extérieur), mais c'est un autre problème.Mais comme le JVM n'a pas de concept de classe intérieure (comme Skafman des États), je me suis demandé comment une visibilité "accessible par une seule classe" est réalisée au niveau de la bytecode. La réponse: il n'est pas du tout réalisé du tout, pour la JVM La classe intérieure ressemble à une classe privée d'emballage normale. Ceci est, si vous écrivez ByTecode pour vous-même (ou modifiez-en une génération génération par le compilateur), vous pouvez accéder à la classe
B sans problèmes.Vous pouvez accéder à toutes les méthodes d'accessoir synthétiques à partir de toutes les classes du même package. Donc, si vous attribuez une valeur à un champ privé de classe
A dans une méthode de classeB , une méthode d'accesseur synthétique avec défaut (package package privé) est générée en classeA (nommé quelque chose commeaccéder à 000 $ ) qui définit la valeur pour vous. Cette méthode n'est censée être appelée uniquement à partir de la classeB (et en effet, elle ne peut être appelée qu'à partir de là à l'aide de la langue Java). Mais du point de vue JVMS, il s'agit simplement d'une méthode comme tout autre et peut être appelée par n'importe quelle classe.Alors, pour répondre à la question:
- du point de vue des langages Java, classe
B est et reste privé.- du point de vue JVMS, classe
B (ou meilleur: classeA $ B ) n'est pas privé.
Correct, mais ce n'est pas ce que j'ai suggéré. J'ai écrit "les membres sont toujours privés" - je voulais dire les champs de la classe et non la catégorie elle-même comme interprétée par vous! Aussi cette question concerne Java et non Bytecode (génération, modification, piratage ...).
@Carlosheuberger, bien sûr, ce n'était pas une offense pour vous! Certainement, les membres de la classe B sont toujours privés, mais la classe B (comme une sorte d'un membre de la classe A) n'est pas (du point de vue de la JVMS), et c'était la question originale de Gérard. Et oui, la question concerne Java, mais comme indiqué dans le tag Wiki: "Java est une langue de programmation et environnement d'exécution ". Et l'environnement d'exécution est le JVM et le JVM en soi n'ont rien à voir avec le langage de programmation Java, mais n'interprète que le bypode.