Methodennamen in Java extrahieren: Der SerializedLambda-Trick

Du kennst das bestimmt: Du arbeitest an einem CSV-Parser, einem ORM-Framework oder einem REST-Client und stehst vor einem lästigen Problem. Du brauchst den Namen eines Feldes als String – aber "author" oder "getTitle" fest reinschreiben? Das fühlt sich einfach falsch an. Refactoring wird zum Albtraum, und plötzlich durchkämmst du den ganzen Code nach verstreuten Strings.

Stell dir stattdessen das hier vor:

String autor = csvInhalt.get(nameOf(Buch::getAutor));
String titel = csvInhalt.get(nameOf(Buch::titel));

Einfach die Methodenreferenz übergeben, und Java kümmert sich um den Rest. Wie das funktioniert, schauen wir uns jetzt an.

Das Problem

Java bietet von Haus aus keine Möglichkeit, an den Namen einer Methode über ihre Referenz ranzukommen. Wenn du Buch::getAutor schreibst, erhältst du ein Function<Buch, String>-Objekt. Aber fragen kannst du es nicht: „Hey, wie heißt du eigentlich?"

Man könnte auf Reflection zurückgreifen:

Method[] methoden = Buch.class.getMethods();
String name = methoden[0].getName(); // Funktioniert – aber welche?

Das Problem: Du musst bereits wissen, welche Methode du suchst. Also eigentlich völlig sinnlos.

Der SerializedLambda-Trick

Hier wird es spannend. Wenn Java ein Lambda oder eine Methodenreferenz serialisiert, entsteht nicht einfach irgendein Bytecode-Wirrnis. Stattdessen erzeugt Java ein SerializedLambda-Objekt. Und das enthält Metadaten zur ursprünglichen Methode – inklusive ihres Namens.

Der Clou: Wir fangen diese Serialisierung ab, bevor sie abgeschlossen ist, und schnappen uns das SerializedLambda-Objekt direkt.

So sieht die Kernimplementierung aus:

public static <T, R> String nameOf(final Getter<T, R> methodRef) {
    return toSerializedLambda(methodRef).getImplMethodName();
}

private static <T, R> SerializedLambda toSerializedLambda(final Object methodRef) {
    try {
        try (CustomObjectOutputStream stream = new CustomObjectOutputStream()) {
            stream.writeObject(methodRef);
            return (SerializedLambda) stream.interceptedObject;
        }
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

Wir erstellen einen eigenen ObjectOutputStream, der den replaceObject-Callback abfängt. Sobald Java unsere Methodenreferenz serialisieren will, ruft es replaceObject mit dem SerializedLambda auf – und genau da greifen wir zu.

Warum das nützlich ist

Mit dieser Technik lassen sich richtig praktische Muster umsetzen:

Typsichere Konfiguration für Datenverarbeitung:

// Statt:
dataMapper.map(buch, "titel", "autor");

// Besser:
dataMapper.map(buch, nameOf(Buch::titel), nameOf(Buch::getAutor));

Kompilierzeit-Sicherheit für API-Aufrufe:

// Datenbankabfragen, die Refactoring überleben
List<Buch> ergebnisse = buchRepo.findBy(nameOf(Buch::getAutor), "Shakespeare");

Wenn du getAutor() umbenennst, markiert der Compiler sofort alle nameOf(Buch::getAutor)-Aufrufe, die angepasst werden müssen. Kein Suchen nach verstreuten Strings mehr.

Auch für Methoden mit Parametern

Das Grundprinzip funktioniert super für parameterlose Methoden. Aber was ist mit komplexeren Signaturen? Da hilft ein erweiterbarer Ansatz mit eigenen funktionalen Interfaces:

public interface BiFunction2<T1, T2, R> extends Serializable {
    R apply(T1 t1, T2 t2);
}

public <T1, T2, R> String nameOf(final BiFunction2<T1, T2, R> methodRef) {
    return toSerializedLambda(methodRef).getImplMethodName();
}

Damit kannst du auch Methoden wie BuchService::findByTitelUndAutor oder Repository::speichern verarbeiten.

Ein paar Einschränkungen

So praktisch die Technik auch ist – es gibt ein paar Punkte zu beachten:

• Performance: Serialisierung hat Overhead. nameOf() nicht in heißen Schleifen aufrufen – einmal während der Initialisierung aufrufen und das Ergebnis cachen.
• Serializable-Requirement: Deine funktionalen Interfaces müssen Serializable erweitern.
• Nicht universell: Das funktioniert nur für Methodenreferenzen, die zu funktionalen Interfaces assignierbar sind. Für beliebige Methoden brauchst du weiterhin direkte Reflection.

Bibliotheken machen es einfacher

Wenn dir das alles zu viel Boilerplate vorkommt: Die Arbeit ist schon erledigt. Die Bibliothek Safety Mirror bietet stabile Implementierungen und erweitert das Konzept sogar, um direkt java.lang.reflect.Method-Objekte zu extrahieren – volle Reflection-Fähigkeiten mit Typsicherheit.

Fazit

Java-Methodenreferenzen sind mächtig, aber sie abstrahieren Methodennamen bewusst weg. Manchmal brauchst du genau diese Metadaten aber zurück. Der SerializedLambda-Trick bietet einen sauberen, typsicheren Weg, diese Lücke zu schließen – expressive, refactoring-freundliche Code ohne magische Strings.

Ob du gerade eine Datenverarbeitungspipeline baust, einen flexiblen API-Client oder einfach nur die Nase voll hast, nach "getAutor" zu suchen: Diese Technik könnte genau das sein, was du brauchst.