Méthode super classe et résolution de conflit de méthode par défaut d’interface

Considérons l’exemple ci-dessous,

public class Testing extends SupCls implements Intf { public static void main(Ssortingng[] args) { new Testing().test(); } } class SupCls { public void test() { System.out.println("From SupCls"); } } interface Intf { public default void test() { System.out.println("From Intf"); } } 

Comme vous pouvez le constater, il n’y a pas de connexion entre la classe Intf et l’interface Intf . Mais les deux définissent une méthode commune.

Et la classe de Testing étend SupCls et implémente Intf .

Ainsi, lorsque j’appelle la méthode test() sur Testing la sortie,

 From SupCls 

Ce qui, à mon avis, a du sens, car l’extension à partir d’une classe devrait avoir une priorité plus élevée que celle à partir d’une interface.

Mais eclipse signale le contraire, comme indiqué dans la capture d’écran ci-dessous.

Capture d'écran d'Eclipse

Je crois fermement qu’il s’agit d’un bug dans Eclipse .

Mais avant de supposer, ce comportement est-il défini et documenté dans le JLS ? Ou y a-t-il autre chose qui définit ce comportement?

Edit: la version Eclipse est la version Mars (4.5.0) , si cela compte.

Votre hypothèse est correcte, la méthode concrète héritée de la superclasse a priorité sur la méthode default de l’ interface :

JLS §8.4.8. Héritage, dérogation et dissimulation

Une classe C hérite de sa super-classe et de ses super-interfaces directes toutes abstract méthodes abstract et par défaut (§9.4) m pour lesquelles toutes les conditions suivantes sont vraies:

  • Aucune méthode déclarée en C n’a une signature qui est une sous-signature (§8.4.2) de la signature de m .
  • Aucune méthode concrète héritée par C de sa super-classe directe n’a une signature qui est une sous-signature de la signature de m .

La deuxième puce citée s’applique ici. Il existe une méthode concrète héritée de la super-classe directe avec une signature appropriée. La méthode default n’est donc pas héritée.

La documentation élimine même tout doute avec une remarque supplémentaire:

Notez qu’il est possible pour une méthode concrète héritée d’empêcher l’inheritance d’une méthode abstraite ou par défaut. (Plus tard, nous affirmerons que la méthode concrète remplace la méthode abstraite ou par défaut “from C”.)

Donc, c’est comme si SupCls.test() annule Intf.test() en ce qui concerne les Testing classe.

En d’autres termes, vous avez raison, c’est un bogue dans Eclipse, mais tant que cela n’affecte que le rendu de la proposition, je le considère comme un bogue mineur . La source insérée sera la même, qu’un D ait été rendu dans la proposition ou non.

C’est certainement un bogue dans eclipse mais dans les propositions d’achèvement du code plutôt que dans le compilateur. En survolant l’appel à tester ou la déclaration ouverte, accédez à la méthode SupCls. L’exécution du code imprime correctement “From SupCls”, ce qui le prouve. S’il vous plaît déposer un bogue contre jdt ui pour enquête

On dirait que la version eclipse est importante!

Dans Eclipse Luna (4.4.1), la référence pointe vers SupCls au lieu de Intf

entrez la description de l'image ici

Probablement un bug dans Eclipse Mars