Analizando expresiones lambda en Java

De un traductor: LambdaMetafactory es quizás uno de los mecanismos Java 8 más subestimados. Lo descubrimos recientemente, pero ya apreciamos sus capacidades. La versión 7.0 del marco CUBA mejora el rendimiento al evitar llamadas reflexivas a favor de generar expresiones lambda. Una de las aplicaciones de este mecanismo en nuestro marco es la vinculación de los controladores de eventos de la aplicación mediante anotaciones, una tarea común, un análogo de EventListener de Spring. Creemos que el conocimiento de los principios de LambdaFactory puede ser útil en muchas aplicaciones Java, y nos apresuramos a compartir esta traducción con usted.

En este artículo, mostraremos algunos trucos poco conocidos al trabajar con expresiones lambda en Java 8 y las limitaciones de estas expresiones. El público objetivo del artículo son los desarrolladores senior de Java, investigadores y desarrolladores de kits de herramientas. Solo se utilizará la API Java pública sin com.sun.* Y otras clases internas, por lo que el código es portátil entre diferentes implementaciones de JVM.

Prólogo corto

Las expresiones Lambda aparecieron en Java 8 como una forma de implementar métodos anónimos y,
en algunos casos, como alternativa a las clases anónimas. En el nivel de bytecode, la expresión lambda se reemplaza por la invokedynamic . Esta instrucción se utiliza para crear una implementación de interfaz funcional y su único método delega la llamada al método real, que contiene el código definido en el cuerpo de la expresión lambda.

Por ejemplo, tenemos el siguiente código:

 void printElements(List<String> strings){ strings.forEach(item -> System.out.println("Item = %s", item)); } 

El compilador de Java convertirá este código en algo similar a:

 private static void lambda_forEach(String item) { // Java  System.out.println("Item = %s", item); } private static CallSite bootstrapLambda(Lookup lookup, String name, MethodType type) { // //lookup =  VM //name = "lambda_forEach",  VM //type = String -> void MethodHandle lambdaImplementation = lookup.findStatic(lookup.lookupClass(), name, type); return LambdaMetafactory.metafactory(lookup, "accept", MethodType.methodType(Consumer.class), //  - MethodType.methodType(void.class, Object.class), //  Consumer.accept    lambdaImplementation, //     - type); } void printElements(List<String> strings) { Consumer<String> lambda = invokedynamic# bootstrapLambda, #lambda_forEach strings.forEach(lambda); } 

La instrucción invokedynamic se puede representar aproximadamente como dicho código Java:

 private static CallSite cs; void printElements(List<String> strings) { Consumer<String> lambda; //begin invokedynamic if (cs == null) cs = bootstrapLambda(MethodHandles.lookup(), "lambda_forEach", MethodType.methodType(void.class, String.class)); lambda = (Consumer<String>)cs.getTarget().invokeExact(); //end invokedynamic strings.forEach(lambda); } 

Como puede ver, LambdaMetafactory se utiliza para crear un CallSite que proporciona un método de fábrica que devuelve un controlador para el método de destino. Este método devuelve la implementación de la interfaz funcional usando invokeExact . Si hay variables capturadas en la expresión lambda, invokeExact acepta estas variables como parámetros reales.

En Oracle JRE 8, metafactory genera dinámicamente una clase Java utilizando ObjectWeb Asm, que crea una clase que implementa una interfaz funcional. Se pueden agregar campos adicionales a la clase creada si la expresión lambda captura variables externas. Este se parece a las clases anónimas de Java, pero existen las siguientes diferencias:

• El compilador de Java genera una clase anónima.
• La clase para implementar la expresión lambda es creada por la JVM en tiempo de ejecución.

La implementación de metafactory depende del proveedor y la versión de JVM

Por supuesto, la invokedynamic no solo se usa para expresiones lambda en Java. Se utiliza principalmente cuando se ejecutan lenguajes dinámicos en el entorno JVM. El motor de JavaScript de Nashorn , que está integrado en Java, hace un uso intensivo de esta instrucción.

A continuación, nos centraremos en la clase LambdaMetafactory y sus capacidades. Siguiente
La sección de este artículo supone que comprende muy bien cómo funcionan los métodos metafactorios y qué MethodHandle

Trucos con expresiones lambda

En esta sección, mostraremos cómo construir lambdas dinámicas para su uso en tareas cotidianas.

Excepciones marcadas y lambdas

No es ningún secreto que todas las interfaces funcionales que existen en Java no admiten excepciones comprobadas. Las ventajas de las excepciones comprobadas sobre las regulares son un debate muy antiguo (y aún candente).

Pero, ¿qué sucede si necesita usar código con excepciones marcadas dentro de expresiones lambda en combinación con Java Streams? Por ejemplo, debe convertir una lista de cadenas en una lista de URL como esta:

 Arrays.asList("http://localhost/", "https://github.com").stream() .map(URL::new) .collect(Collectors.toList()) 

Se declara una excepción arrojable en el constructor de la URL (String) , por lo que no se puede usar directamente como referencia de método en la clase Functiion .

Dirás: "No, quizás si usas este truco aquí":

 public static <T> T uncheckCall(Callable<T> callable) { try { return callable.call(); } catch (Exception e) { return sneakyThrow(e); } } private static <E extends Throwable, T> T sneakyThrow0(Throwable t) throws E { throw (E)t; } public static <T> T sneakyThrow(Throwable e) { return Util.<RuntimeException, T>sneakyThrow0(e); } //   //return s.filter(a -> uncheckCall(a::isActive)) // .map(Account::getNumber) // .collect(toSet()); 

Este es un truco sucio. Y aquí está el por qué:

• Se utiliza el bloque try-catch.
• La excepción se lanza nuevamente.
• El uso sucio del tipo borrado en Java.

El problema puede resolverse de una manera más "legal", utilizando el conocimiento de los siguientes hechos:

• Las excepciones marcadas se reconocen solo en el nivel del compilador Java.
• La sección de throws son solo metadatos para un método sin un valor semántico en el nivel JVM.
• Las excepciones marcadas y normales no se pueden distinguir a nivel de bytecode en la JVM.

La solución es envolver el método Callable.call en un método sin una sección de throws :

 static <V> V callUnchecked(Callable<V> callable){ return callable.call(); } 

Este código no se compila porque el método Callable.call declarado excepciones comprobadas en la sección de throws . Pero podemos eliminar esta sección usando una expresión lambda construida dinámicamente.

Primero necesitamos declarar una interfaz funcional que no tenga una sección de throws .
pero quién podrá delegar la llamada a Callable.call :

 @FunctionalInterface interface SilentInvoker { MethodType SIGNATURE = MethodType.methodType(Object.class, Callable.class);//  INVOKE <V> V invoke(final Callable<V> callable); } 

El segundo paso es crear una implementación de esta interfaz usando LambdaMetafactory y delegar la llamada del método Callable.call método Callable.call . Como se mencionó anteriormente, la sección de throws se ignora en el nivel de bytecode, por lo que el método SilentInvoker.invoke puede llamar al método Callable.call sin declarar excepciones:

 private static final SilentInvoker SILENT_INVOKER; final MethodHandles.Lookup lookup = MethodHandles.lookup(); final CallSite site = LambdaMetafactory.metafactory(lookup, "invoke", MethodType.methodType(SilentInvoker.class), SilentInvoker.SIGNATURE, lookup.findVirtual(Callable.class, "call", MethodType.methodType(Object.class)), SilentInvoker.SIGNATURE); SILENT_INVOKER = (SilentInvoker) site.getTarget().invokeExact(); 

Tercero, escribimos un método auxiliar que llama a Callable.call sin declarar excepciones:

 public static <V> V callUnchecked(final Callable<V> callable) /*no throws*/ { return SILENT_INVOKER.invoke(callable); } 

Ahora puede reescribir la secuencia sin ningún problema con excepciones marcadas:

 Arrays.asList("http://localhost/", "https://dzone.com").stream() .map(url -> callUnchecked(() -> new URL(url))) .collect(Collectors.toList()); 

Este código se compila sin problemas porque callUnchecked no declara excepciones comprobadas. Además, llamar a este método se puede incorporar mediante el almacenamiento en caché en línea monomórfico , porque es solo una clase en toda la JVM que implementa la interfaz SilentOnvoker

Si la implementación de Callable.call arroja una excepción en tiempo de ejecución, la función de llamada la detectará sin ningún problema:

 try{ callUnchecked(() -> new URL("Invalid URL")); } catch (final Exception e){ System.out.println(e); } 

A pesar de las posibilidades de este método, siempre debe recordar la siguiente recomendación:

Oculte las excepciones marcadas con callUnchecked solo si está seguro de que el código llamado no arrojará ninguna excepción

El siguiente ejemplo muestra un ejemplo de este enfoque:

 callUnchecked(() -> new URL("https://dzone.com")); // URL        MalformedURLException 

La implementación completa de este método está aquí , es parte del proyecto de código abierto SNAMP .

Trabajando con Getters y Setters

Esta sección será útil para quienes escriben serialización / deserialización para varios formatos de datos como JSON, Thrift, etc. Además, puede ser bastante útil si su código depende en gran medida de la reflexión para Getters y Setters en JavaBeans.

Un getter declarado en JavaBean es un método llamado getXXX sin parámetros y un tipo de datos de retorno que no sea void . Un setter declarado en JavaBean es un método llamado setXXX , con un parámetro y regresando void . Estas dos notaciones se pueden representar como interfaces funcionales:

• Getter puede ser representado por la clase Function , en la cual el argumento es el valor de this .
• Setter puede ser representado por la clase BiConsumer , en la cual el primer argumento es this , y el segundo es el valor que se pasa a Setter.

Ahora crearemos dos métodos que pueden convertir cualquier getter o setter en estos
interfaces funcionales Y no importa que ambas interfaces sean genéricas. Después de borrar tipos
El tipo de datos real será Object . La conversión automática del tipo de retorno y los argumentos se pueden hacer usando LambdaMetafactory . Además, la biblioteca Guava ayudará a almacenar en caché las expresiones lambda para los mismos captadores y establecedores.

Primer paso: crear un caché para captadores y establecedores. La clase Method de Reflection API representa un captador o setter real y se usa como clave.
El valor de caché es una interfaz funcional construida dinámicamente para un getter o setter específico.

 private static final Cache<Method, Function> GETTERS = CacheBuilder.newBuilder().weakValues().build(); private static final Cache<Method, BiConsumer> SETTERS = CacheBuilder.newBuilder().weakValues().build(); 

En segundo lugar, crearemos métodos de fábrica que creen una instancia de la interfaz funcional basada en referencias a getter o setter.

 private static Function createGetter(final MethodHandles.Lookup lookup, final MethodHandle getter) throws Exception{ final CallSite site = LambdaMetafactory.metafactory(lookup, "apply", MethodType.methodType(Function.class), MethodType.methodType(Object.class, Object.class), //signature of method Function.apply after type erasure getter, getter.type()); //actual signature of getter try { return (Function) site.getTarget().invokeExact(); } catch (final Exception e) { throw e; } catch (final Throwable e) { throw new Error(e); } } private static BiConsumer createSetter(final MethodHandles.Lookup lookup, final MethodHandle setter) throws Exception { final CallSite site = LambdaMetafactory.metafactory(lookup, "accept", MethodType.methodType(BiConsumer.class), MethodType.methodType(void.class, Object.class, Object.class), //signature of method BiConsumer.accept after type erasure setter, setter.type()); //actual signature of setter try { return (BiConsumer) site.getTarget().invokeExact(); } catch (final Exception e) { throw e; } catch (final Throwable e) { throw new Error(e); } } 

La conversión automática de tipos entre argumentos de tipo Object en interfaces funcionales (después del borrado de tipo) y tipos reales de argumentos y valor de retorno se logra utilizando la diferencia entre samMethodType y instantiatedMethodType (el tercer y quinto argumento del método metafactorio, respectivamente). El tipo de la instancia creada del método: esta es la especialización del método que proporciona la implementación de la expresión lambda.

En tercer lugar, crearemos una fachada para estas fábricas con soporte para el almacenamiento en caché:

 public static Function reflectGetter(final MethodHandles.Lookup lookup, final Method getter) throws ReflectiveOperationException { try { return GETTERS.get(getter, () -> createGetter(lookup, lookup.unreflect(getter))); } catch (final ExecutionException e) { throw new ReflectiveOperationException(e.getCause()); } } public static BiConsumer reflectSetter(final MethodHandles.Lookup lookup, final Method setter) throws ReflectiveOperationException { try { return SETTERS.get(setter, () -> createSetter(lookup, lookup.unreflect(setter))); } catch (final ExecutionException e) { throw new ReflectiveOperationException(e.getCause()); } } 

La información del método obtenida de una instancia de la clase Method utiliza la API de Java Reflection se puede convertir fácilmente en un MethodHandle . Tenga en cuenta que los métodos de instancia de clase siempre tienen un primer argumento oculto utilizado para pasar this a este método. Los métodos estáticos no tienen dicho parámetro. Por ejemplo, la firma real del método Integer.intValue() se ve como int intValue(Integer this) . Este truco se utiliza en nuestra implementación de envoltorios funcionales para captadores y establecedores.

Y ahora es el momento de probar el código:

 final Date d = new Date(); final BiConsumer<Date, Long> timeSetter = reflectSetter(MethodHandles.lookup(), Date.class.getDeclaredMethod("setTime", long.class)); timeSetter.accept(d, 42L); //the same as d.setTime(42L); final Function<Date, Long> timeGetter = reflectGetter(MethodHandles.lookup(), Date.class.getDeclaredMethod("getTime")); System.out.println(timeGetter.apply(d)); //the same as d.getTime() //output is 42 

Este enfoque con getters y setters almacenados en caché se puede usar de manera efectiva en las bibliotecas de serialización / deserialización (como Jackson) que usan getters y setters durante la serialización y deserialización.

Llamar a interfaces funcionales con implementaciones generadas dinámicamente usando LambdaMetaFactory significativamente más rápido que llamar a través de la API de Java Reflection

La versión completa del código se puede encontrar aquí , es parte de la biblioteca SNAMP .

Limitaciones y errores

En esta sección, veremos algunos errores y limitaciones asociados con las expresiones lambda en el compilador de Java y JVM. Todas estas limitaciones se pueden reproducir en OpenJDK y Oracle JDK con javac versión 1.8.0_131 para Windows y Linux.

Crear expresiones lambda a partir de manejadores de métodos

Como sabe, una expresión lambda se puede construir dinámicamente usando LambdaMetaFactory . Para hacer esto, debe definir un controlador: la clase MethodHandle , que indica la implementación del único método definido en la interfaz funcional. Echemos un vistazo a este sencillo ejemplo:

 final class TestClass { String value = ""; public String getValue() { return value; } public void setValue(final String value) { this.value = value; } } final TestClass obj = new TestClass(); obj.setValue("Hello, world!"); final MethodHandles.Lookup lookup = MethodHandles.lookup(); final CallSite site = LambdaMetafactory.metafactory(lookup, "get", MethodType.methodType(Supplier.class, TestClass.class), MethodType.methodType(Object.class), lookup.findVirtual(TestClass.class, "getValue", MethodType.methodType(String.class)), MethodType.methodType(String.class)); final Supplier<String> getter = (Supplier<String>) site.getTarget().invokeExact(obj); System.out.println(getter.get()); 

Este código es equivalente a:

 final TestClass obj = new TestClass(); obj.setValue("Hello, world!"); final Supplier<String> elementGetter = () -> obj.getValue(); System.out.println(elementGetter.get()); 

Pero, ¿qué sucede si reemplazamos el manejador de métodos que apunta a getValue con el manejador que representan los campos getter?

 final CallSite site = LambdaMetafactory.metafactory(lookup, "get", MethodType.methodType(Supplier.class, TestClass.class), MethodType.methodType(Object.class), lookup.findGetter(TestClass.class, "value", String.class), //field getter instead of method handle to getValue MethodType.methodType(String.class)); 

Este código debería, como se esperaba, funcionar porque findGetter devuelve un controlador que apunta a los campos getter y tiene la firma correcta. Pero, si ejecuta este código, verá la siguiente excepción:

 java.lang.invoke.LambdaConversionException: Unsupported MethodHandle kind: getField 

Curiosamente, el captador para el campo funciona bien si usamos MethodHandleProxies :

 final Supplier<String> getter = MethodHandleProxies .asInterfaceInstance(Supplier.class, lookup.findGetter(TestClass.class, "value", String.class) .bindTo(obj)); 

Cabe señalar que MethodHandleProxies no es una buena manera de crear dinámicamente expresiones lambda, porque esta clase simplemente envuelve MethodHandle en una clase proxy y delega invocationHandler.invoke a MethodHandle.invokeWithArguments . Este enfoque utiliza Java Reflection y es muy lento.

Como se mostró anteriormente, no todos los manejadores de métodos se pueden usar para crear expresiones lambda en tiempo de ejecución.

Solo se pueden usar unos pocos tipos de manejadores de métodos para crear dinámicamente expresiones lambda.

Aquí están:

• REF_invokeInterface: se puede crear usando Lookup.findVirtual para métodos de interfaz
• REF_invokeVirtual: se puede crear usando Lookup.findVirtual para métodos virtuales de clase
• REF_invokeStatic: creado usando Lookup.findStatic para métodos estáticos
• REF_newInvokeSpecial: se puede crear usando Lookup.findConstructor para constructores
• REF_invokeSpecial: se puede crear usando Lookup.findSpecial
  para métodos privados y enlace temprano con métodos virtuales de clase

Otros tipos de controladores LambdaConversionException error LambdaConversionException .

Excepciones Genéricas

Este error está relacionado con el compilador de Java y la capacidad de declarar excepciones genéricas en la sección de throws . El siguiente ejemplo de código demuestra este comportamiento:

 interface ExtendedCallable<V, E extends Exception> extends Callable<V>{ @Override V call() throws E; } final ExtendedCallable<URL, MalformedURLException> urlFactory = () -> new URL("http://localhost"); urlFactory.call(); 

Este código debe compilarse porque el constructor de la clase URL arroja una MalformedURLException . Pero no se compila. Se muestra el siguiente mensaje de error:

 Error:(46, 73) java: call() in <anonymous Test$CODEgt; cannot implement call() in ExtendedCallable overridden method does not throw java.lang.Exception 

Pero, si reemplazamos la expresión lambda con una clase anónima, entonces el código compila:

 final ExtendedCallable<URL, MalformedURLException> urlFactory = new ExtendedCallable<URL, MalformedURLException>() { @Override public URL call() throws MalformedURLException { return new URL("http://localhost"); } }; urlFactory.call(); 

De esto se desprende:

La inferencia de tipos para excepciones genéricas no funciona correctamente en combinación con expresiones lambda

Limitaciones de tipo de parametrización

Puede construir un objeto genérico con varias restricciones de tipo utilizando el signo & : <T extends A & B & C & ... Z> .
Este método de determinación de parámetros genéricos rara vez se usa, pero de cierta manera afecta las expresiones lambda en Java debido a algunas restricciones:

• Cada restricción de tipo, excepto la primera, debe ser una interfaz.
• Una versión pura de una clase con tal genérico solo tiene en cuenta la primera restricción de tipo de la lista.

La segunda limitación conduce a diferentes comportamientos del código en tiempo de compilación y en tiempo de ejecución, cuando se produce el enlace a la expresión lambda. Esta diferencia se puede demostrar usando el siguiente código:

 final class MutableInteger extends Number implements IntSupplier, IntConsumer { //mutable container of int value private int value; public MutableInteger(final int v) { value = v; } @Override public int intValue() { return value; } @Override public long longValue() { return value; } @Override public float floatValue() { return value; } @Override public double doubleValue() { return value; } @Override public int getAsInt() { return intValue(); } @Override public void accept(final int value) { this.value = value; } } static <T extends Number & IntSupplier> OptionalInt findMinValue(final Collection <T> values) { return values.stream().mapToInt(IntSupplier::getAsInt).min(); } final List <MutableInteger> values = Arrays.asList(new MutableInteger(10), new MutableInteger(20)); final int mv = findMinValue(values).orElse(Integer.MIN_VALUE); System.out.println(mv); 

Este código es absolutamente correcto y se compila con éxito. La clase MutableInteger satisface las restricciones del tipo genérico T:

• MutableInteger hereda de Number .
• MutableInteger implementa IntSupplier .

Pero el código se bloqueará con una excepción en tiempo de ejecución:

 java.lang.BootstrapMethodError: call site initialization exception at java.lang.invoke.CallSite.makeSite(CallSite.java:341) at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307) at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297) at Test.minValue(Test.java:77) Caused by: java.lang.invoke.LambdaConversionException: Invalid receiver type class java.lang.Number; not a subtype of implementation type interface java.util.function.IntSupplier at java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:233) at java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:303) at java.lang.invoke.CallSite.makeSite(CallSite.java:302) 

Esto sucede porque la canalización JavaStream captura solo un tipo puro, que, en nuestro caso, es la clase Number y no implementa la interfaz IntSupplier . Este problema se puede solucionar declarando explícitamente el tipo de parámetro en un método separado, utilizado como referencia al método:

 private static int getInt(final IntSupplier i){ return i.getAsInt(); } private static <T extends Number & IntSupplier> OptionalInt findMinValue(final Collection<T> values){ return values.stream().mapToInt(UtilsTest::getInt).min(); } 

Este ejemplo demuestra una inferencia de tipo incorrecta en el compilador y el tiempo de ejecución.

El manejo de múltiples restricciones de tipo de parámetro genérico junto con el uso de expresiones lambda en tiempo de compilación y en tiempo de ejecución no es consistente