Erste Schritte Anfängerfrage zu ::new

[pkm]

Ich habe gesehen, dass man mit der Syntax von Lambdaausdrücken auch den Konstruktor mit dem ::-Operator aufrufen kann. Dass man auf eine Methode mit :: zugreifen kann, kenne ich nur aus der Iteration über Listen, z. B.

List<String> myList = new Arraylist<>();
  myList.add("eins");
  myList.add("zwei");

myList.forEach(System.out::println);

Aber in welchen Fällen wird sonst mit dem ::-Operator auf Methoden zugegriffen und vor allem, wann wird mit dem ::-Operator auf new zugegriffen :new)?

 

[httpdigest]

Ersteinmal ein bisschen zum Hintergrund von Lambda-Ausdrücken in Java:
Ein Lambda-Ausdruck ist nur "syntaktischer Zucker" für die automatische Implementierung eines Interfaces mit nur einer abstrakten (also nicht-default) Methode, wobei die tatsächliche Implementierung leichtgewichtiger ist als eine normale Klasse oder anonyme Klasse. Im Java-Umfeld nennt man solche Interfaces, die nur eine abstrakte Methode haben, neuerdings auch "functional Interfaces" und es gibt sogar eine Annotation, die reinen Dokumentationscharakter hat, um sowas auch zu dokumentieren: java.lang.FunctionalInterface.
Es hängt jetzt vom Anwendungskontext ab, wo genau Lambda-Ausdrücke erlaubt sind. Sie sind überall dort erlaubt, wo man sonst eine Instanz eines funktionalen Interfaces angeben müsste. Also z.B. wenn man einer Variablen von solch einem Interfacetyp einen Wert zuweisen möchte:

Supplier<String> s = () -> "Hello";

Supplier ist dabei das java.util.function.Supplier Interface, und es hat genau eine Methode mit der Signatur: `T get()`, also die Methode bekommt keinen Parameter, liefert aber ein T zurück. Was das T dann genau ist, liefert das Typargument bei der konkreten Instanziierung der Klasse, die das Interface implementiert.
Eine weitere Stelle, an der man Lambda-Ausdrücke anwenden kann (und das ist wohl die häufigste), ist als Argument für Methodenparameter vom Typ eines funktionalen Interfaces. Schaue dir z.B. einmal folgende Methodensignatur an:

<T> T give(Supplier<T> s)

Eine solche Methode _könnte_ nun den obigen Lambda-Ausdruck bekommen, und z.B. folgendes tun:

<T> T give(Supplier<T> s) {
  return s.get();
}
void main() {
  String str = give(() -> "Hello");
}

Sie kann also einen Supplier auswerten, und zum Zeitpunkt der Auswertung den Wert liefern, den der Supplier zu diesem Zeitpunkt liefert. Das ist interessant für "Lazy Evaluation", in der man Berechnungen erstmal als Lambda-Funktionen (sprich: Implementierungen eines funktionalen Interfaces) bereithalten möchte, um sie dann bei Bedarf auszuwerten.
Zugegeben, das sind alles ausgedachte Beispiele, aber ich finde es wichtig, dass man erstmal genau festhält, was ein Lambda-Ausdruck eigentlich genau ist.
Kommen wir jetzt zu Methodenreferenzen. Methodenreferenzen sind weiterer syntaktischer Zucker, um das funktionale Interface in solch einer Form zu implementieren, dass die Implementierung der abstrakten Methode einfach nur die Methode, dessen Referenz man angibt, aufruft.
Im obigen Beispiel könnte man also schreiben:

<T> T give(Supplier<T> s) {
  return s.get();
}
String sayHello() {
  return "Hello";
}
void main() {
  String str = give(this::sayHello);
}

Siehst du, was hier passiert? Die Methodenreferenz auf die Instanzmethode "sayHello" ist kompatibel zur Signatur der Methode "get" im Supplier, in der Form, als dass beide keinen Parameter bekommen und ein T zurückliefern. Das T ist in diesem Fall nun instanziiert mit String und schon haben wir einen kompatiblen Aufruf über das Supplier Interface auf unsere sayHello Methode.
Mehr sind Methodenreferenzen nicht. Nur ein syntaktisches Mittel, um eine Instanzmethode, statische Methode oder Konstruktor auf ein funktionales Interface zu "adaptieren".
Jetzt noch kurz zu Konstruktoren. Die Signatur einer Referenz eines Konstruktors hat immer als Rückgabetyp den Typ, der der Konstruktur instanziiert (bzw. initialisiert) und genau die Parameter, die auch der Konstruktor hat.
Ein "no-args" Konstruktor, der also keine Parameter bekommt, wäre immer kompatibel zum Supplier-Interface, da in beiden Fällen Methoden gemeint sind, die keine Parameter bekommen, und ein T zurückliefern.
Unser Beispiel weitergespinnt, könnte man z.B: sowas machen:

    <T, C extends Collection<T>> C transform(Collection<? extends T> coll, Supplier<C> f) {
        C ret = f.get();
        ret.addAll(coll);
        return ret;
    }
 
    void main(String[] args) {
        List<String> arrayList = new ArrayList<>();
        Set<String> set = transform(arrayList, HashSet::new);
    }

Das geht natürlich viel kürzer mit `set = new HashSet(arrayList)`, aber es soll erstmal nur aufzeigen, was Konstruktorreferenzen genau sind.
Jetzt aber zu der Frage: Wann wird das denn alles gebraucht? Lambda-Ausdrücke, Methodenreferenzen und Konstruktorreferenzen? Das alles sind zumindest mal Versuche, funktionale Programmierung in die eigentlich stark objektorientierte JVM-Welt zu bekommen. Ich persönlich benutze Lambdausdrücke und Methodenreferenzen eigentlich nie. Es gab bisher noch keine wirklichen Anwendungsfälle für mich.
Ein Grund dafür kann z.B. auch sein, dass Java noch keine starke Typinferenz unterstützt, wie etwa Haskell, und deswegen jede Benutzung und auch selbstentwickelte Methoden mit funktionalen Interface ein wahres Monster an Generics-Typendeklarationen werden.
Die JVM ist eben doch in ihrem Kern rein objektorientiert und hat Funktionen nicht als First-Class-Citizens, sodass funktionale Programmierung erst wirklich Sinn macht. Aber jetzt schweife ich ab.

 

[mrBrown]

es gibt sogar eine Annotation, die reinen Dokumentationscharakter hat, um sowas auch zu dokumentieren: java.lang.FunctionalInterface.

Nicht nur Dokumentationscharakter, die Annotation auf nicht passendem Typen führt auch zu einem Compile-Fehler (analog zu z.B. @Override)

Ich persönlich benutze Lambdausdrücke und Methodenreferenzen eigentlich nie. Es gab bisher noch keine wirklichen Anwendungsfälle für mich.
Ein Grund dafür kann z.B. auch sein, dass Java noch keine starke Typinferenz unterstützt, wie etwa Haskell, und deswegen jede Benutzung und auch selbstentwickelte Methoden mit funktionalen Interface ein wahres Monster an Generics-Typendeklarationen werden.

Ich benutze die ziemlich häufig, um mal etwas Gewicht auf die andere Seite der Waage zu legen

Allerdings stoß ich eher selten an die Grenzen der Typinferenz, wo muss man denn da wahre Monster erschaffen?

 

[httpdigest]

Nicht nur Dokumentationscharakter, die Annotation auf nicht passendem Typen führt auch zu einem Compile-Fehler (analog zu z.B. @Override)

Oh, nice! Stimmt. Sie führt dann zu einem anderen weit hilfreicheren Fehler als wenn man die Annotation weglassen würde. Danke für die Info!

 

[pkm]

Vielen Dank für die detaillierten Antworten. Diese haben mir sehr geholfen.