Comment fonctionnent les expressions lambda et que se passe-t-il 'sous le capot' ?

Les expressions lambda en Java fonctionnent grâce aux mécanismes suivants :

1. Interfaces fonctionnelles : L'expression lambda doit être assignée à une variable, renvoyée par une méthode ou passée à une méthode dont le type est une interface fonctionnelle. Une interface fonctionnelle est une interface avec exactement une méthode abstraite (SAM - Single Abstract Method). L'annotation @FunctionalInterface est optionnelle, mais recommandée pour la vérification par le compilateur.

2. Invocation dynamique (invokeDynamic) : Au lieu de générer une classe interne anonyme dans le bytecode lors de la compilation, comme c'était le cas dans les anciennes versions, Java utilise l'instruction invokeDynamic. Cette instruction a été ajoutée en Java 7 pour supporter les langages dynamiquement typés sur la JVM, et en Java 8, elle est utilisée pour implémenter les expressions lambda et les références de méthodes. invokeDynamic reporte la résolution de l'appel de méthode à l'exécution (runtime).

Ce qui se passe 'en coulisses' :

Au moment de la compilation :

• Le compilateur analyse l'expression lambda.
• Il détermine le type de l'interface fonctionnelle à laquelle elle se réfère.
• Il génère une méthode synthétique spéciale (souvent avec le préfixe lambda$) dans la même classe contenant la logique de la lambda. Cette méthode a la même signature que la méthode abstraite de l'interface fonctionnelle.
• À l'endroit où la lambda est utilisée, le compilateur génère l'instruction invokeDynamic. Cette instruction contient une référence à bootstrap method (LambdaMetafactory.metafactory).

Au moment de l'exécution (runtime) :

• Lorsque la JVM rencontre l'instruction invokeDynamic, elle appelle pour la première fois le bootstrap method (LambdaMetafactory.metafactory).
• La bootstrap method génère dynamiquement en mémoire un call site.
• Le call site crée et retourne une instance d'une classe qui implémente l'interface fonctionnelle. Cette instance peut être :
  • Créée à la volée (par exemple, à l'aide d'un Constant CallSite généré).
  • Mise en cache pour une utilisation ultérieure (pour les lambdas sans état).
  • Représentée comme une référence à une instance existante de l'interface fonctionnelle (par exemple, pour les lambdas sans état qui implémentent Serializable).
• Cette classe générée délègue l'appel à la méthode abstraite de l'interface fonctionnelle à la méthode synthétique générée par le compilateur (lambda$).
• Après le premier appel au bootstrap method, le call site se souvient de l'objet à retourner, et les appels suivants à invokeDynamic pour la même lambda peuvent rapidement obtenir cet objet ou l'appeler directement sans réinvocation du bootstrap method.

Ainsi, les lambdas ne créent pas toujours une nouvelle classe à chaque instanciation. Pour les lambdas qui ne capturent pas de variables du contexte externe (lambdas sans état), l'implémentation de l'interface fonctionnelle peut être un singleton ou une instance mise en cache et réutilisée. Les lambdas capturant des variables (lambdas avec état) nécessitent la création d'une nouvelle instance de classe qui stockera les variables capturées.

L'utilisation de invokeDynamic permet au compilateur JIT d'optimiser l'exécution des appels de méthodes d'interfaces fonctionnelles de manière plus efficace que le modèle traditionnel des classes anonymes, car le JIT peut prendre des décisions plus informées en temps d'exécution.

// Exemple d'interface fonctionnelle
@FunctionalInterface
interface MyFunction {
    String apply(String input);
}

public class LambdaExample {
    public static void main(String[] args) {
        // Utilisation d'une expression lambda
        MyFunction func = s -> "Processed: " + s;

        String result = func.apply("Test");
        System.out.println(result);
    }
}