Estoy ejecutando a continuación en el método principal:
int secrete = 42; for (int i = 0; i < 5; i++) { Consumer<String> myprinter2 = msg -> { System.out.println("consuming " + msg + " ," + secrete); }; myprinter2.accept(myprinter2.toString()); }La salida para el código anterior es:
consuming Main$$Lambda$1/1324119927@6d311334 ,42 consuming Main$$Lambda$1/1324119927@682a0b20 ,42 consuming Main$$Lambda$1/1324119927@3d075dc0 ,42 consuming Main$$Lambda$1/1324119927@214c265e ,42 consuming Main$$Lambda$1/1324119927@448139f0 ,42 Si cambio secrete para que sea final, entonces el resultado es:
consuming Main$$Lambda$1/2003749087@41629346 ,42 consuming Main$$Lambda$1/2003749087@41629346 ,42 consuming Main$$Lambda$1/2003749087@41629346 ,42 consuming Main$$Lambda$1/2003749087@41629346 ,42 consuming Main$$Lambda$1/2003749087@41629346 ,42 secrete es efectivamente final incluso si no lo declaro final, entonces, ¿por qué cada lambda se considera un nuevo objeto cuando no lo declaro final?
"Efectivamente final" no es técnicamente necesario, se podría haber hecho sin él. Pero los diseñadores del lenguaje pusieron esta restricción para evitar confusiones, porque si la variable seguía cambiando, ¿qué valor vería la lambda, el inicial o el último? Otros lenguajes que tienen lambda no tienen esta restricción y la especificación establece la expectativa para este caso de uso.
Dado el siguiente código:
import java.util.function.Consumer; class Main { public static void main(String args[]) { int i = 42; final int j = 41; for (int k = 0; k < 5; k++) { Consumer<String> x = msg -> System.out.printf("x=%s, i=%d%n", msg, i); Consumer<String> y = msg -> System.out.printf("y=%s, j=%d%n", msg, j); Consumer<String> z = msg -> System.out.printf("z=%s%n", msg); x.accept(x.toString()); y.accept(y.toString()); z.accept(z.toString()); } } } Cuando inspeccionamos el bytecode generado con javap -c -v Main.class , vemos:
11: invokedynamic #7, 0 // InvokeDynamic #0:accept:(I)Ljava/util/function/Consumer; 16: astore_3 17: invokedynamic #11, 0 // InvokeDynamic #1:accept:()Ljava/util/function/Consumer; 22: astore 4 24: invokedynamic #14, 0 // InvokeDynamic #2:accept:()Ljava/util/function/Consumer; Podemos ver cómo se traducen las lambdas. Los métodos static correspondientes muestran que la primera lambda es una lambda de captura y tiene un primer parámetro entero (#71) después de la traducción, mientras que las otras no.
BootstrapMethods: 0: #63 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; Method arguments: #70 (Ljava/lang/Object;)V #71 REF_invokeStatic Main.lambda$main$0:(ILjava/lang/String;)V #74 (Ljava/lang/String;)V 1: #63 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; Method arguments: #70 (Ljava/lang/Object;)V #75 REF_invokeStatic Main.lambda$main$1:(Ljava/lang/String;)V #74 (Ljava/lang/String;)V 2: #63 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; Method arguments: #70 (Ljava/lang/Object;)V #78 REF_invokeStatic Main.lambda$main$2:(Ljava/lang/String;)V #74 (Ljava/lang/String;)VEntonces, así es como se traducen las lambdas. Puedes encontrar más detalles en este artículo .