Warum müssen this() und super() die erste Anweisung in einem Konstruktor sein?

Question

Java schreibt vor, dass der Aufruf von this() oder super() in einem Konstruktor die erste Anweisung sein muss. Warum?

Zum Beispiel:

public class MyClass {
    public MyClass(int x) {}
}

public class MySubClass extends MyClass {
    public MySubClass(int a, int b) {
        int c = a + b;
        super(c);  // COMPILE ERROR
    }
}

Der Sun-Compiler sagt: "Der Aufruf von super muss die erste Anweisung im Konstruktor sein". Der Eclipse-Compiler sagt: "Constructor call must be the first statement in a constructor".

Sie können dies jedoch umgehen, indem Sie den Code ein wenig umgestalten:

public class MySubClass extends MyClass {
    public MySubClass(int a, int b) {
        super(a + b);  // OK
    }
}

Hier ein weiteres Beispiel:

public class MyClass {
    public MyClass(List list) {}
}

public class MySubClassA extends MyClass {
    public MySubClassA(Object item) {
        // Create a list that contains the item, and pass the list to super
        List list = new ArrayList();
        list.add(item);
        super(list);  // COMPILE ERROR
    }
}

public class MySubClassB extends MyClass {
    public MySubClassB(Object item) {
        // Create a list that contains the item, and pass the list to super
        super(Arrays.asList(new Object[] { item }));  // OK
    }
}

Es ist also Sie nicht daran hindern, die Logik auszuführen vor dem Anruf beim Hausmeister. Es hält Sie nur davon ab, Logik auszuführen, die Sie nicht in einen einzigen Ausdruck packen können.

Es gibt ähnliche Regeln für den Aufruf this() . Der Compiler sagt: "Der Aufruf von this muss die erste Anweisung im Konstruktor sein".

Warum hat der Compiler diese Einschränkungen? Können Sie ein Codebeispiel nennen, bei dem etwas Schlimmes passieren würde, wenn der Compiler diese Einschränkung nicht hätte?

Answer 1

Der Konstruktor der übergeordneten Klasse muss vor dem Konstruktor der Unterklasse aufgerufen werden. Dadurch wird sichergestellt, dass, wenn Sie in Ihrem Konstruktor Methoden der übergeordneten Klasse aufrufen, die übergeordnete Klasse bereits korrekt eingerichtet wurde.

Was Sie versuchen zu tun, übergeben Sie Args an den Superkonstruktor ist völlig legal, Sie müssen nur diese Args inline konstruieren, wie Sie tun, oder übergeben Sie in Ihrem Konstruktor und dann übergeben Sie an super :

public MySubClassB extends MyClass {
        public MySubClassB(Object[] myArray) {
                super(myArray);
        }
}

Wenn der Compiler dies nicht erzwingen würde, könnten Sie dies tun:

public MySubClassB extends MyClass {
        public MySubClassB(Object[] myArray) {
                someMethodOnSuper(); //ERROR super not yet constructed
                super(myArray);
        }
}

In Fällen, in denen eine übergeordnete Klasse einen Standardkonstruktor hat, wird der Aufruf von super automatisch vom Compiler eingefügt. Da jede Klasse in Java erbt von Object Der Konstruktor des Objekts muss irgendwie aufgerufen und zuerst ausgeführt werden. Die automatische Einfügung von super() durch den Compiler ermöglicht dies. Dadurch, dass super() zuerst erscheinen muss, wird erzwungen, dass die Konstruktorkörper in der richtigen Reihenfolge ausgeführt werden, nämlich Objekt -> Parent -> Child -> ChildOfChild -> SoOnSoForth

Answer 2

Ich habe einen Weg gefunden, dies durch Verkettung von Konstruktoren und statischen Methoden zu umgehen. Was ich tun wollte, sah in etwa so aus:

public class Foo extends Baz {
  private final Bar myBar;

  public Foo(String arg1, String arg2) {
    // ...
    // ... Some other stuff needed to construct a 'Bar'...
    // ...
    final Bar b = new Bar(arg1, arg2);
    super(b.baz()):
    myBar = b;
  }
}

Man konstruiert also ein Objekt auf der Grundlage von Konstruktorparametern, speichert das Objekt in einem Member und übergibt das Ergebnis einer Methode für dieses Objekt an den Konstruktor von super. Es war auch ziemlich wichtig, das Mitglied final zu machen, da die Klasse von Natur aus unveränderlich ist. Beachten Sie, dass die Konstruktion von Bar tatsächlich einige Zwischenobjekte erfordert, so dass sie in meinem tatsächlichen Anwendungsfall nicht auf einen Einzeiler reduziert werden kann.

Am Ende habe ich es etwa so gemacht:

public class Foo extends Baz {
  private final Bar myBar;

  private static Bar makeBar(String arg1,  String arg2) {
    // My more complicated setup routine to actually make 'Bar' goes here...
    return new Bar(arg1, arg2);
  }

  public Foo(String arg1, String arg2) {
    this(makeBar(arg1, arg2));
  }

  private Foo(Bar bar) {
    super(bar.baz());
    myBar = bar;
  }
}

Legaler Code, der die Aufgabe erfüllt, vor dem Aufruf des Superkonstruktors mehrere Anweisungen auszuführen.

Answer 3

Weil die JLS das sagt. Könnte das JLS in einer kompatiblen Weise geändert werden, um dies zu ermöglichen? Jawohl.

Allerdings würde dies die Sprachspezifikation verkomplizieren, die bereits mehr als kompliziert genug ist. Es wäre nicht sehr nützlich und es gibt Möglichkeiten, es zu umgehen (Aufruf eines anderen Konstruktors mit dem Ergebnis einer statischen Methode oder eines Lambda-Ausdrucks this(fn()) - die Methode wird vor dem anderen Konstruktor und damit auch vor dem Superkonstruktor aufgerufen). Das Verhältnis zwischen Leistung und Gewicht der Änderung ist also ungünstig.

Beachten Sie, dass diese Regel allein die Verwendung von Feldern nicht verhindert, bevor die Superklasse ihre Konstruktion abgeschlossen hat.

Betrachten Sie diese illegalen Beispiele.

super(this.x = 5);

super(this.fn());

super(fn());

super(x);

super(this instanceof SubClass);
// this.getClass() would be /really/ useful sometimes.

Dieses Beispiel ist legal, aber "falsch".

class MyBase {
    MyBase() {
        fn();
    }
    abstract void fn();
}
class MyDerived extends MyBase {
    void fn() {
       // ???
    }
}

Im obigen Beispiel, wenn MyDerived.fn erforderlichen Argumente aus dem MyDerived Konstruktor müssten sie mit einer ThreadLocal . ;(

Übrigens: Seit Java 1.4 enthält das synthetische Feld, das die äußere this zugewiesen wird, bevor der Superkonstruktor der inneren Klassen aufgerufen wird. Dies verursachte merkwürdige NullPointerException Ereignisse in Code, der für frühere Versionen kompiliert wurde.

Beachten Sie auch, dass bei einer unsicheren Veröffentlichung die Konstruktion von anderen Threads neu geordnet werden kann, wenn keine Vorsichtsmaßnahmen getroffen werden.

Bearbeiten März 2018: In der Nachricht Aufzeichnungen: Aufbau und Validierung Oracle schlägt vor, diese Einschränkung zu entfernen (aber im Gegensatz zu C#, this wird sein definitiv nicht zugewiesen (DU) vor der Verkettung der Konstruktoren).

Historisch gesehen, muss this() oder super() in einem Konstruktor an erster Stelle stehen. Diese Beschränkung war nie beliebt und wurde als willkürlich empfunden. Es gab eine Reihe von subtilen Gründen, einschließlich der Überprüfung von invokespecial, die zu dieser Einschränkung beigetragen haben. Im Laufe der Jahre haben wir diese auf der VM-Ebene angegangen, bis zu dem Punkt, an dem es dass es sinnvoll ist, diese Einschränkung aufzuheben, nicht nur für Records, sondern für alle Konstruktoren.

Answer 4

Ganz einfach, weil dies die Philosophie der Vererbung ist. Und gemäß der Java-Spezifikation ist der Körper des Konstruktors so definiert:

ConstructorBody: { ExplicitConstructorInvocation _optieren    BlockStatements _optieren }

Die erste Anweisung eines Konstruktorkörpers kann entweder sein

• ein expliziter Aufruf eines anderen Konstruktors derselben Klasse (unter Verwendung des Schlüsselworts "this"); oder
• ein expliziter Aufruf der direkten Oberklasse (durch Verwendung des Schlüsselworts "super")

Wenn ein Konstruktorkörper nicht mit einem expliziten Konstruktoraufruf beginnt und der deklarierte Konstruktor nicht Teil der ursprünglichen Klasse Object ist, dann beginnt der Konstruktorkörper implizit mit einem Superklassen-Konstruktoraufruf "super();", einem Aufruf des Konstruktors seiner direkten Superklasse, der keine Argumente annimmt. Und so weiter es gibt eine ganze Kette von Konstruktoren, die bis zum Konstruktor von Object zurückgehen; "Alle Klassen in der Java-Plattform sind Nachkommen von Object". Diese Sache wird " Verkettung von Konstruktoren ".

Warum ist das so?
Und der Grund, warum Java den ConstructorBody auf diese Weise definiert hat, ist, dass sie es brauchten, um die Hierarchie aufrechtzuerhalten des Objekts. Erinnern Sie sich an die Definition der Vererbung: Es ist die Erweiterung einer Klasse. Das heißt, man kann nicht etwas erweitern, das es nicht gibt. Die Basis (die Oberklasse) muss zuerst erstellt werden, dann kann man sie ableiten (die Unterklasse). Deshalb nennt man sie auch Eltern- und Kind-Klassen; man kann kein Kind ohne Elternteil haben.

Technisch gesehen erbt eine Unterklasse alle Mitglieder (Felder, Methoden, verschachtelte Klassen) von ihrer Mutterklasse. Und da Konstruktoren KEINE Mitglieder sind (sie gehören nicht zu Objekten, sondern sind für die Erstellung von Objekten zuständig), werden sie NICHT an Unterklassen vererbt, können aber aufgerufen werden. Und da bei der Erstellung eines Objekts wird nur EIN Konstruktor ausgeführt . Wie können wir also die Erstellung der Oberklasse garantieren, wenn Sie das Objekt der Unterklasse erstellen? Daher das Konzept der "Konstruktorverkettung"; wir haben also die Möglichkeit, andere Konstruktoren (d. h. Superklassen) aus dem aktuellen Konstruktor heraus aufzurufen. Und Java verlangt, dass dieser Aufruf die ERSTE Zeile im Unterklassenkonstruktor sein muss, um die Hierarchie aufrechtzuerhalten und zu garantieren. Sie gehen davon aus, dass, wenn Sie das übergeordnete Objekt nicht explizit ZUERST erstellen (z. B. wenn Sie es vergessen haben), sie es implizit für Sie tun werden.

Diese Prüfung wird während der Kompilierung durchgeführt. Aber ich bin mir nicht sicher, was zur Laufzeit passieren würde, welche Art von Laufzeitfehler wir bekommen würden, WENN Java keinen Kompilierfehler auslöst, wenn wir explizit versuchen, einen Basiskonstruktor aus dem Konstruktor einer Unterklasse in der Mitte seines Körpers auszuführen und nicht aus der allerersten Zeile ...

Answer 5

Ich bin mir ziemlich sicher (diejenigen, die mit der Java-Spezifikation vertraut sind, mögen sich dazu äußern), dass dies verhindern soll, dass Sie (a) ein teilweise konstruiertes Objekt verwenden dürfen und (b) den Konstruktor der übergeordneten Klasse zwingen, ein "frisches" Objekt zu konstruieren.

Einige Beispiele für eine "schlechte" Sache wären:

class Thing
{
    final int x;
    Thing(int x) { this.x = x; }
}

class Bad1 extends Thing
{
    final int z;
    Bad1(int x, int y)
    {
        this.z = this.x + this.y; // WHOOPS! x hasn't been set yet
        super(x);
    }        
}

class Bad2 extends Thing
{
    final int y;
    Bad2(int x, int y)
    {
        this.x = 33;
        this.y = y; 
        super(x); // WHOOPS! x is supposed to be final
    }        
}