ActionListener

[Alpha11833]

Hallo,

ich habe ein Problem:

private JPanel createSomePanel() {
    List<Integer> i0 = new ArrayList<>();
    Integer i1;
    irgendEinButton.addActionListener(new ActionListener() {
       @Override
       public void actionPerformed(ActionEvent arg0) {
         i0.add(2);  // Funktioniert
         i1 = 12;  // Funktioniert nicht
       }
     });
}

Fehler bei "Funktioniert nicht": i1 cannot be resolved or is not a field
und: Local variable i1 defined in an enclosing scope must be final or effectively final

Warum findet er die Liste i0, aber den Integer i1 nicht?


LG

 

[Flown]

Wenn du etwas Google-Suche betreibst, dann wirst du schnell fündig, dass dieser ActionListener auf einen äußere Scope-Variable zugreift (Closure). Es ist in der JLS niedergeschrieben, dass zwar die innere (in deinem Fall anonyme) Klasse auf äußere Variable lesend zugreifen kann, aber nicht schreiben. Bei deiner Liste änderst du nicht die Variable, sondern veränderst den Zustand. Es gibt dafür ein paar Workarounds, wie zum Beispiel ein int-Array mit Länge 1 zu verwenden, oder du nimmst die dafür vorgesehene Klassen Atomic<Primitives> (Primitives = Boolean, Integer, Double, ...).

Ein paar Sachen zum Nachlesen: JLS, SO#1, SO#2

 

[Alpha11833]

Wenn du etwas Google-Suche betreibst, dann wirst du schnell fündig, dass dieser ActionListener auf einen äußere Scope-Variable zugreift (Closure). Es ist in der JLS niedergeschrieben, dass zwar die innere (in deinem Fall anonyme) Klasse auf äußere Variable lesend zugreifen kann, aber nicht schreiben. Bei deiner Liste änderst du nicht die Variable, sondern veränderst den Zustand. Es gibt dafür ein paar Workarounds, wie zum Beispiel ein int-Array mit Länge 1 zu verwenden, oder du nimmst die dafür vorgesehene Klassen Atomic<Primitives> (Primitives = Boolean, Integer, Double, ...).

Ein paar Sachen zum Nachlesen: JLS, SO#1, SO#2

Yes Sir.. Danke! Das Problem ist manchmal, dass man nicht das richtige findet, wenn man nicht weiß, wonach man suchen muss Danke, dass du das jetzt gemacht hast

LG

 

[Zet]

@alpha
und i0.add(2) funktionierte?

 

[Ch4t4r]

Ja, du kannst nicht das eigentliche Objekt verändern, wohl aber alle in diesem Objekt enthaltenen Objekte. Während
du ein Array in einer anonymen Klasse nicht erneut initialisieren kannst (z.B. über array = new int[]) kannst du dessen Werte ändern (array[42] = 1). Nicht anders ist es mit der Liste.

 

[Zet]

public class createSomePanel
{

    JButton irgendEinButton = new JButton();

    private JPanel createSomePanel()
    {

        final List<Integer> i0 = new ArrayList<Integer>();

        Integer i1;

        irgendEinButton.addActionListener(new ActionListener()
        {

            @Override
            public void actionPerformed(ActionEvent arg0)
            {
                i0.add(2); // Funktioniert

                i1 = 12; // Funktioniert nicht

            }

        });
        return null;

    }
}

i0.add(2) funktioniert bei mir nur wenn ich i0 als final deklariere.
Oder liegt es an meiner (leidergottes..) JRE 1.6?

 

[Ch4t4r]

Tut es nicht, damit stellt java sicher, dass das Objekt nicht geändert wird. Trotzdem gilt alles, was ich oben geschrieben habe.
Um das final zum umgehen, kannst du im Scope deine Liste einen weiter nach oben verschieben, also in den Sichtbarkeitsbereich der Klasse (innerhalb von

public class Klasse{
//hier
}

Dort wird kein final verlangt.

 

[Flown]

@Zet ab Java 8 (glaub ich) ist der Compiler schlau genug "effectively final" zu erkennen und man muss das final nicht extra mehr dazuschreiben.

 

[Kobold137]

Kann es daran liegen das er Integer sagt und nicht int ?
Meine das Problem auch schonmal gehabt zu haben das er einfach int will und nicht Integer

Kann es leider grad nicht selbst ausprobieren.

LG

Kobold

 

[Flown]

Also das hat jetzt nichts mit int oder Integer zu tun. Wie ich bereits sagte ist das ein Closure-Problem! Du willst aus einem anderen Scope eine Referenz setzen (bzw. bei int i1 einen neuen Wert). Das ist in Java aber nicht erlaubt, darum beschwert sich der Compiler, das nur final Variablen in einer inneren Klasse eingesetzt werden darf. Da du die Referenz der Liste - also i0 - nicht änderst, sondern deren Zustand, ist das kein Problem (in früheren Java Versionen, wie @Zet schon beschrieben hat, muss man final für alle Variablen, die in einer inneren Klasse verwendet werden, schreiben).
Klassenvariablen hingegen, können bedenkenlos geändert werden, da sie nicht im MethodenStack liegen, sondern im Heap (aber das ist wieder ein anderes Thema).