Pourquoi this() et super() doivent-ils être la première instruction d'un constructeur ?

Question

Java exige que si vous appelez this() ou super() dans un constructeur, ce doit être la première déclaration. Pourquoi ?

Par exemple :

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
    }
}

Le compilateur Sun dit "l'appel à super doit être la première déclaration du constructeur". Le compilateur Eclipse dit "L'appel au constructeur doit être la première déclaration dans un constructeur".

Cependant, vous pouvez contourner ce problème en réorganisant un peu le code :

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

Voici un autre exemple :

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
    }
}

Donc, c'est ne vous empêche pas d'exécuter la logique avant l'appel au super. Il vous empêche simplement d'exécuter une logique que vous ne pouvez pas faire tenir dans une seule expression.

Il existe des règles similaires pour appeler this() . Le compilateur dit "l'appel à this doit être la première déclaration du constructeur".

Pourquoi le compilateur a-t-il ces restrictions ? Pouvez-vous donner un exemple de code où, si le compilateur n'avait pas cette restriction, quelque chose de mauvais se produirait ?

Answer 1

Le constructeur de la classe mère doit être appelé avant le constructeur de la sous-classe. Cela garantit que si vous appelez des méthodes de la classe mère dans votre constructeur, la classe mère a déjà été configurée correctement.

Ce que vous essayez de faire, passer les args au super constructeur est parfaitement légal, vous devez juste construire ces args en ligne comme vous le faites, ou les passer dans votre constructeur et ensuite les passer au super :

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

Si le compilateur ne l'imposait pas, vous pourriez le faire :

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

Dans les cas où une classe parente possède un constructeur par défaut, l'appel à super est inséré automatiquement par le compilateur. Puisque chaque classe en Java hérite de Object Le constructeur de l'objet doit être appelé d'une manière ou d'une autre et doit être exécuté en premier. L'insertion automatique de super() par le compilateur permet cela. En forçant super à apparaître en premier, on s'assure que les corps des constructeurs sont exécutés dans l'ordre correct qui serait : Objet -> Parent -> Enfant -> EnfantOfChild -> SoOnSoForth

Answer 2

J'ai trouvé un moyen de contourner ce problème en enchaînant les constructeurs et les méthodes statiques. Ce que je voulais faire ressemblait à quelque chose comme ceci :

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;
  }
}

En gros, il s'agit de construire un objet en fonction des paramètres du constructeur, de stocker l'objet dans un membre et de passer le résultat d'une méthode sur cet objet dans le constructeur de super. Rendre le membre final était aussi raisonnablement important car la nature de la classe est qu'elle est immuable. Notez qu'en fait, la construction de Bar prend quelques objets intermédiaires, donc ce n'est pas réductible à une ligne unique dans mon cas d'utilisation réel.

J'ai fini par faire en sorte que ça marche comme ça :

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;
  }
}

Code légal, et il accomplit la tâche d'exécuter plusieurs déclarations avant d'appeler le super constructeur.

Answer 3

Parce que le JLS le dit. Le JLS pourrait-il être modifié de manière compatible pour l'autoriser ? Yup.

Cependant, cela compliquerait les spécifications du langage, qui sont déjà plus que compliquées. Ce ne serait pas une chose très utile à faire et il existe des moyens de contourner le problème (appeler un autre constructeur avec le résultat d'une méthode statique ou d'une expression lambda). this(fn()) - la méthode est appelée avant l'autre constructeur, et donc aussi le super constructeur). Le rapport poids/puissance de cette modification est donc défavorable.

Notez que cette règle seule n'empêche pas l'utilisation des champs avant que la super classe ait terminé sa construction.

Considérez ces exemples illégaux.

super(this.x = 5);

super(this.fn());

super(fn());

super(x);

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

Cet exemple est légal, mais "incorrect".

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

Dans l'exemple ci-dessus, si MyDerived.fn les arguments requis de la MyDerived il faudrait les passer au crible d'un constructeur de ThreadLocal . ;(

D'ailleurs, depuis Java 1.4, le champ synthétique qui contient l'adresse externe de l'utilisateur est remplacé par une adresse externe. this est assigné avant que le super constructeur des classes internes soit appelé. Cela a causé des problèmes particuliers NullPointerException dans le code compilé pour cibler les versions antérieures.

Notez également qu'en présence d'une publication non sécurisée, la construction peut être vue réordonnée par d'autres fils, à moins que des précautions ne soient prises.

Édition mars 2018 : Dans le message Enregistrements : construction et validation Oracle propose de supprimer cette restriction (mais contrairement à C#, this sera définitivement non attribué (DU) avant le chaînage des constructeurs).

Historiquement, this() ou super() doit être le premier dans un constructeur. Cette restriction restriction n'a jamais été populaire, et perçue comme arbitraire. Il y avait un certain nombre de raisons subtiles, y compris la vérification de invokespecial, qui ont contribué à cette restriction. Au fil des années, nous avons abordé ces raisons au niveau de la VM, au point qu'il devient pratique d'envisager de lever cette restriction, non seulement pour les enregistrements mais pour tous les constructeurs.

Answer 4

Je suis à peu près sûr (ceux qui connaissent bien la spécification Java peuvent nous en parler) que c'est pour vous empêcher (a) d'être autorisé à utiliser un objet partiellement construit, et (b) de forcer le constructeur de la classe parente à construire sur un objet "frais".

Voici quelques exemples d'une "mauvaise" chose :

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
    }        
}

Answer 5

Vous avez demandé pourquoi, et les autres réponses, à mon avis, ne disent pas vraiment pourquoi il est acceptable d'appeler le constructeur de votre super, mais seulement si c'est la toute première ligne. La raison est que vous n'êtes pas vraiment en appelant le constructeur. En C++, la syntaxe équivalente est

MySubClass: MyClass {

public:

 MySubClass(int a, int b): MyClass(a+b)
 {
 }

};

Lorsque vous voyez la clause d'initialisation seule comme ça, avant l'accolade ouverte, vous savez que c'est spécial. Elle s'exécute avant tout le reste du constructeur et, en fait, avant que les variables membres ne soient initialisées. Ce n'est pas si différent pour Java. Il existe un moyen de faire en sorte que du code (d'autres constructeurs) s'exécute avant que le constructeur ne démarre réellement, avant que les membres de la sous-classe ne soient initialisés. Ce moyen consiste à placer l'"appel" (ex. super ) sur la toute première ligne. (D'une certaine manière, ce super ou this est en quelque sorte avant la première accolade ouverte, même si vous le tapez après, car il sera exécuté avant que vous n'arriviez au point où tout est entièrement construit). Tout autre code après l'accolade ouverte (comme int c = a + b; ) fait dire au compilateur "oh, ok, pas d'autres constructeurs, nous pouvons tout initialiser alors". Il s'exécute donc et initialise votre super classe et vos membres et ainsi de suite, puis commence à exécuter le code après l'accolade ouverte.

Si, quelques lignes plus tard, il rencontre du code disant "oh oui, lorsque vous construisez cet objet, voici les paramètres que je veux que vous transmettiez au constructeur de la classe de base", il est trop tard et cela n'a aucun sens. Donc vous obtenez une erreur de compilation.