Phänomen bei Klassendateien von 'Inneren Klassen'

Hallo!

Ich habe folgendes ausprobiert: Ich habe eine Klasse geschrieben. Diese Klasse hat eine Methode mit der ein Objekt einer inneren Klasse dieser Klasse erzeugt werden kann. Dabei wird der Typ der zu verwendenden inneren Klassen als String übergeben - es steht also nicht fest, von welchem Typ das innere Objekt sein wird.

Die äußere Klasse selbst enthält aber überhaupt keine inneren Klassen. Ich compiliere alles und speichere die class - Datei dieser äußeren Klasse in einem anderen Verzeichnis ab.

Wenn ich jetzt den Quellcode umschreibe und eine innere Klasse in dieser äußeren Klasse programmiere und einfach die class - Datei der neuen inneren Klasse (ÄußereKlasse$InnereKlasse.class) zu der alten class - Datei der äußeren Klasse in dieses andere Verzeichnis kopiere OHNE die Datei der äußeren Klasse zu aktualisieren, kann ich trotzdem Objekte der neuen ineren Klasse erzeugen!!! Also ich rufe (aus einer anderen Klasse heraus) die „NeuesInneresObjekt“ - Methode der (alten) äußeren Klasse auf und spezifiziere den Namen der zu verwendenden inneren Klasse - und das funktioniert auch mit der ALTEN class-Datei der äußeren Klasse - also mit der wo die innere Klasse noch gar nicht bekannt war.

Die schlichte und einfache Frage dazu ist: Ist diese Verfahrensweise unbedenklich oder kann man das wirklich so machen (vorausgesetzt die äußere Klasse ändert sich strukturell nicht mehr)???

Florian

Wie holst du dir die innere Klasse in deiner Methode? Mit Class.forName(„AuessereKlasse.InnereKlasse“)?
Dann ist das dem Classloader egal, er findet die Klasse in der Datei AuessereKlasse$InnereKlasse.class und gut ist :smile:
Sollte allerdings nur mit static inner classes gehen und dort auch immer funktionieren. Ist allerdings fraglich wofür man dieses Verhalten sinnvollerweise brauchen könnte, da dass ohne inner classes genauso funktioniert :wink:

Grüße
Bruno

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hallo!

Wie holst du dir die innere Klasse in deiner Methode? Mit
Class.forName(„AuessereKlasse.InnereKlasse“)?

Mit forName natürlich. getDeclaredClasses funzt nicht weil es ja nicht in der .class - Datei d. alten äußeren Klasse stehen kann.

Dann ist das dem Classloader egal, er findet die Klasse in der
Datei AuessereKlasse$InnereKlasse.class und gut ist :smile:
Sollte allerdings nur mit static inner classes gehen und dort
auch immer funktionieren. Ist allerdings fraglich wofür man
dieses Verhalten sinnvollerweise brauchen könnte, da dass ohne
inner classes genauso funktioniert :wink:

Spaßvogel :smile:. Natürlich rede ich von Elementklassen - also nichtstatischen inneren Klassen. Der Punkt ist ja: Die inneren Klassen greifen ja direkt auf Elemente der äußeren Klasse zu. Deswegen wäre ja zumindest theoretisch zu vermuten, dass auch die .class - Datei der äußeren Klasse entsprechende Angaben enthalten muss, damit eine (nichtstatische) innere Klasse einwandfrei funktioniert. Ich habe rausgefunden, dass man nichtstatische innere Klassen problemlos auf die äußere Klasse loslassen kann, auch wenn die innere Klasse der äußeren Klasse zum Zeitpunkt als die .class - Datei der äußeren Klasse erstellt wurde, noch unbekannt war.

Florian

Hallo,
innere Klassen kennt die VM nicht. Insofern werden Deine nichtstatischen Klassen einfach durch den Compiler zu etwas verwurstet, was eine Referenz auf die Instanz der äußeren Klassen unter der sie erzeugt werden im Konstruktor enthält.

Gruss
Enno