statisches Feld in lokaler Klasse. Sinnlos!

[Wladimir]

habe eine lokale Klasse

class PersonPanel
{
 ...
 private void createPanel ()
 {
  ...
  // lokale Klasse
  Action action = new Action ("Submit") {
   private static String name = "ActionCode123";
   ...
  }
  ...
  button = myFactor.createButton (action);
  ...
 }
...
}

Nun meine Frage.
Sind meine Gedanken richtig?

1) Static ist nicht nötig, da es nie eine zweite Instanz einer lokalen Klasse geben kann.
2) Kann es wirklich nie eine 2te Instanz einer lokalen Klasse geben?
3) Wenn ich eine 2te PersonPanel Instanz habe, ist action dann nicht die 2te Instanz des selbten Typs "Action ("Submit")"?

Ich nehme an lokale Klassen sind für jede Instanz der umschliessenden Klasse eindeutig.
Somit macht static in lokalen Klassen keinen Sinn.

 

[Marco13]

Und um nicht ZU viel Unfug zu erzählen hab ich gerade mal versucht, sowas zu compilieren, da sagt er mir
"inner classes cannot have static declarations"
... :roll:
Was soll es auch bringen, ein statisches Feld in einer (anonymen!!!) inneren Klasse zu haben. Man hat ja NIE Zugriff auf die Klasse, sondern IMMER nur auf die Instanzen....

 

[SlaterB]

man könnte mal
object.getClass().newInstance()
versuchen,
ist bestimmt verboten für anonyme Klassen

 

[Wladimir]

Action action = new Action ("Submit") {
   private final static String name = "ActionCode123";
   ...
  }

compiliert.

Das stimmt, "static" alleine kann in inneren Klasse nicht verwendet werden. Erst mit "final" ist es wiederum möglich.
Wieso aber dann "final static" erlaubt ist. Ist wohl alleine weil es überlich ist "final" mit "static" zu kombinieren.

object.getClass().newInstance()

liefert klarerweise eine InstationException[/code]

 

[Spacerat]

Hallo,

... und vorallem, was soll das mit private final? Auf dieses statische Feld (im übrigen genau wie die serialVersionUID) kann scheinbar wirklich nur die Anonyme Klasse zugreifen, da sie ja selbst in der umgebenden Klasse nicht mal namentlich bekannt ist! OK... Die Lösung für derartige Konstrukte findet man im JNI-Bereich (Java Native Interface) der JVM. Über JNI kann man jederzeit auf private oder protegierte Klassen-Member (Felder und Methoden transient oder statisch) ausserhalb der Klasse zugreifen. Wenn jemandem z.B. in Fremdcode eine "vergessene" private Methode über den Weg läuft (Eclipse zeigt dann eine Warnung), sollte diese erst dann "gekillt" werden, wenn sichergestellt ist, das keine native Library zu diesem Paket gehört!

Ach... und genau deswegen ist es keinesfalls SINNLOS!!!

cu Spacerat