Funktionale Interfaces mit mehreren abstrakten Methoden?

[udem]

Hallo liebe Mitglieder,

wodurch erkennt ein Compiler, ob ein Interface eine Methode eines anderen Interfaces überschreibt?
Es findet schließlich kein Einsatz von Codes, wie "implements" oder "extends" statt, die dies signalisieren könnten
und eine Annotation wie @Override ist nicht vorgeschrieben.

Hintergrund der Frage ist zu verstehen, wie ein Compiler ein Funktionales Interface mit mehreren abstrakten Methoden (z.B. Comparator) als solches erkennt
und nicht als gewöhnliches Interface interpretiert.

Freundliche Grüße
U.D.

 

[DrPils]

Ein Funktionales Interface definiert immer genau eine abstrakte Methode, statische und Default Methoden können dabei beliebig viele existieren. Schau dir den Comperator Mal an. Dann siehst du das nur eine Methode abstrakt ist.

 

[udem]

Ein Funktionales Interface definiert immer genau eine abstrakte Methode, statische und Default Methoden können dabei beliebig viele existieren. Schau dir den Comperator Mal an. Dann siehst du das nur eine Methode abstrakt ist.

Neben den vielen default-Methoden sehe ich compare() und equals().

 

[KonradN]

Neben den vielen default-Methoden sehe ich compare() und equals().

Ja, das ist auch korrekt. Die Aussage mit der "genau eine abstrakte Methode" ist etwas ungenau. Es ist nur genau eine abstrakte Methode mit Ausnahme von Methoden der Klasse Object. Siehe dazu: JLS 9.8: https://docs.oracle.com/javase/specs/jls/se20/html/jls-9.html#jls-9.8

A functional interface is an interface that is not declared sealed and has just one abstract method (aside from the methods of Object), and thus represents a single function contract.

equals ist in Comparator, aber das ist auch eine Methode in Object.

 

[httpdigest]

Naja, das Interface deklariert ganz genau nur eine abstrakte Methode. equals() und hashCode() und toString(), etc. werden ja nicht von diesem Interface deklariert.

 

[KonradN]

Naja, das Interface deklariert ganz genau nur eine abstrakte Methode. equals() und hashCode() und toString(), etc. werden ja nicht von diesem Interface deklariert.

openjdk-jdk11/Comparator.java at master · AdoptOpenJDK/openjdk-jdk11 (github.com)

@FunctionalInterface
public interface Comparator<T> {
   
    int compare(T o1, T o2);
   
    boolean equals(Object obj);

    // ...
}

Also extrem stark gekürzt und Kommentare weggelassen und so. Aber dieses Interface Comparator deklariert genau dies.

Edit: Tippfehler

 

[DrPils]

Es ist nur genau eine abstrakte Methode mit Ausnahme von Methoden der Klasse Object.

Aber wieso tut man das? Ist ja jetzt nicht so dass ich jetzt equals überschreiben muss.
Rein zu Dokumentationszwecken?

 

[KonradN]

Aber wieso tut man das? Ist ja jetzt nicht so dass ich jetzt equals überschreiben muss.
Rein zu Dokumentationszwecken?

Ja, nach meinem Verständnis dient dies nur zur Dokumentation wichtiger Dinge in Zusammenhang mit der Methode. Aus Java Sicht macht es keinen Unterschied, ob du die abstrakte Methode im Interface hast oder nicht - mit Ausnahme der Sichtbarkeit: clone in Object ist protected, wird die Methode im Interface verlangt, dann wird eine public Implementation verpflichtend. Aber das ist mir so noch nicht unter gekommen.

Dazu findet sich auch etwas in der JLS unter 9.8.

 

[KonradN]

Also da evtl. auch kurz zu der Relevanz: Die Antworten #2 (@DrPils) und #5 (@httpdigest) zeigen die „normale“ Sichtweise. Funktionales Interface = 1 abstract Method. Das mit Object ist eigentlich nicht wirklich relevant für die Praxis. Das ist mehr was für „Verrückte“, die Spaß daran haben, die JLS unter dem Kopfkissen liegen zu haben oder so.

Die Aussage von Dir @DrPils ist daher so auch weiterhin mit Like versehen und die würde ich so im Forum auch immer so bringen. Denn das ist in der Praxis nach meiner Erfahrung durchaus so. (JDK Framework Entwickler haben halt alle die JLS unter dem Kopfkissen … daher hat Comparator auch equals drin 🙂 )