Inferencia de tipo de reflexión en Java 8 Lambdas

La decisión exacta de cómo asignar el código lambda a las implementaciones de la interfaz se deja al entorno de tiempo de ejecución real. En principio, todos los lambdas que implementan la misma interfaz raw podrían compartir una sola clase de tiempo de ejecución como MethodHandleProxies lo hace. El uso de diferentes clases para lambdas específicas es una optimización realizada por la implementación real LambdaMetafactory, pero no una característica destinada a ayudar a la depuración o Reflexión.

Así que incluso si usted encuentra información más detallada en el real clase de tiempo de ejecución de una implementación de interfaz lambda será un artefacto del entorno de tiempo de ejecución utilizado actualmente que podría no estar disponible en una implementación diferente o incluso en otras versiones de su entorno actual.

Si la lambda es Serializable puede usar el hecho de que la forma serializada contiene la firma del método del tipo de interfaz instanciado para unir los valores de la variable de tipo real.

Esto es actualmente posible de resolver, pero solo de una manera bastante hackie, pero permítanme primero explicar algunas cosas:

Cuando se escribe una lambda, el compilador inserta una instrucción dynamic invoke apuntando a LambdaMetafactory y un método sintético estático privado con el cuerpo de la lambda. El método sintético y el identificador del método en el grupo de constantes contienen el tipo genérico (si lambda usa el tipo o es explícito como en sus ejemplos).

Ahora en runtime se llama a LambdaMetaFactory y se genera una clase usando ASM que implementa la interfaz funcional y el cuerpo del método luego llama al método estático privado con cualquier argumento pasado. Luego se inyecta en la clase original usando Unsafe.defineAnonymousClass (ver John Rose post) para que pueda acceder a los miembros privados, etc.

Desafortunadamente la Clase generada no almacena las firmas genéricas (podría), por lo que no puede usar los métodos de reflexión habituales que le permiten moverse borrado

Para una Clase normal puedes inspeccionar el bytecode usando Class.getResource(ClassName + ".class") pero para las clases anónimas definidas usando Unsafe no tienes suerte. Sin embargo, puedes hacer que LambdaMetaFactory los vuelque con el argumento JVM:

java -Djdk.internal.lambda.dumpProxyClasses=/some/folder

Al mirar el archivo de clase volcado (usando javap -p -s -v), uno puede ver que efectivamente llama al método estático. Pero el problema sigue siendo cómo obtener el bytecode desde dentro de Java.

Por desgracia, aquí es donde se pone hackie:

Usando reflexión podemos llamar a Class.getConstantPool y luego acceder al MethodRefInfo para obtener los descriptores de tipo. Entonces podemos usar ASM para analizar esto y devolver los tipos de argumento. Poniendo todo junto:

Method getConstantPool = Class.class.getDeclaredMethod("getConstantPool");
getConstantPool.setAccessible(true);
ConstantPool constantPool = (ConstantPool) getConstantPool.invoke(lambda.getClass());
String[] methodRefInfo = constantPool.getMemberRefInfoAt(constantPool.size() - 2);

int argumentIndex = 0;
String argumentType = jdk.internal.org.objectweb.asm.Type.getArgumentTypes(methodRef[2])[argumentIndex].getClassName();
Class<?> type = (Class<?>) Class.forName(argumentType);

Actualizado con la sugerencia de jonathan

Ahora idealmente las clases generadas por LambdaMetaFactory deberían almacenar las firmas de tipo genéricas (podría ver si puedo enviar un parche al OpenJDK) pero actualmente esto es lo mejor que podemos hacer. El código anterior tiene la problemas siguientes:

• Utiliza métodos y clases no documentados
• Es extremadamente vulnerable a los cambios de código en el JDK
• No conserva los tipos genéricos, por lo que si pasa List a una lambda, aparecerá como List

La información de tipo parametrizado solo está disponible en tiempo de ejecución para los elementos de código que están enlazados, es decir, compilados específicamente en un tipo. Lambdas hace lo mismo, pero como su Lambda está des-azucarado a un método en lugar de a un tipo, no hay ningún tipo para capturar esa información.

Considere lo siguiente:

import java.util.Arrays;
import java.util.function.Function;

public class Erasure {

    static class RetainedFunction implements Function<Integer,String> {
        public String apply(Integer t) {
            return String.valueOf(t);
        }
    }

    public static void main(String[] args) throws Exception {
        Function<Integer,String> f0 = new RetainedFunction();
        Function<Integer,String> f1 = new Function<Integer,String>() {
            public String apply(Integer t) {
                return String.valueOf(t);
            }
        };
        Function<Integer,String> f2 = String::valueOf;
        Function<Integer,String> f3 = i -> String.valueOf(i);

        for (Function<Integer,String> f : Arrays.asList(f0, f1, f2, f3)) {
            try {
                System.out.println(f.getClass().getMethod("apply", Integer.class).toString());
            } catch (NoSuchMethodException e) {
                System.out.println(f.getClass().getMethod("apply", Object.class).toString());
            }
            System.out.println(Arrays.toString(f.getClass().getGenericInterfaces()));
        }
    }
}

f0 y f1 ambos conservan su información de tipo genérico, como es de esperar. Pero como son métodos no vinculados que se han borrado a Function<Object,Object>, f2 y f3 no.

Recientemente he añadido soporte para resolver argumentos de tipo lambda a TypeTools. Ex:

MapFunction<String, Integer> fn = str -> Integer.valueOf(str);
Class<?>[] typeArgs = TypeResolver.resolveRawArguments(MapFunction.class, fn.getClass());

Los args de tipo resuelto son los esperados:

assert typeArgs[0] == String.class;
assert typeArgs[1] == Integer.class;

Para manejar una lambda pasada:

public void call(Callable<?> c) {
  // Assumes c is a lambda
  Class<?> callableType = TypeResolver.resolveRawArguments(Callable.class, c.getClass());
}

Nota: La implementación subyacente utiliza el enfoque de ConstantPool descrito por @danielbodart que se sabe que funciona en Oracle JDK y OpenJDK (y posiblemente otros).