Java MethodHandle.asType 适配方法签名：可转换参数、返回值与调用点校验

把一个已知的 Java 静态方法交给插件或表达式层调用时，MethodHandle 的签名必须先对上调用点。asType 可以创建一个拥有新签名的适配句柄，让参数在进入目标方法前转换、让返回值在离开目标方法后转换；但它不会替你解决参数个数或不可转换类型的问题。

先记住一条边界：asType 负责可行的类型适配，invokeExact 仍要求调用点类型与句柄类型完全一致；适配失败时应检查 WrongMethodTypeException。

一个“明明参数能转却调用失败”的现场

下面的目标方法只有一个 String 参数并返回 int。如果直接把它当成 (Object)Object 去精确调用，调用点描述和句柄描述不同，问题不在目标方法，而在调用协议没有完成适配。

static int lengthOf(String value) {
    return value.length();
}

排查第一步不是修改业务方法，而是把签名打印出来：

System.out.println(target.type());
// (String)int

这里的 String 和 int 是后续判断的证据。Java SE API 说明，MethodHandle 是强类型的；invokeExact 要求调用点类型与句柄的 type() 完全匹配。

先把查找、适配和调用拆成三层

MethodHandles.lookup 与 findStatic 只负责找到目标

MethodHandles.lookup() 得到查找器，findStatic 按类名、方法名和原始 MethodType 定位静态方法。查找阶段的签名应该写成真实方法签名，否则还没到适配阶段就会失败。

MethodHandles.Lookup lookup = MethodHandles.lookup();
MethodHandle target = lookup.findStatic(
        Demo.class,
        "lengthOf",
        MethodType.methodType(int.class, String.class));

这一步成功后，target.type() 应为 (String)int。如果名称或原始类型写错，优先检查 findStatic 的查找条件，不要把错误归因于 asType。

asType 产生新的适配句柄

现在把调用侧需要的签名设成 (Object)Integer：

MethodType callSiteType = MethodType.methodType(Integer.class, Object.class);
MethodHandle adapted = target.asType(callSiteType);
System.out.println(adapted.type());
// (Object)Integer

适配句柄收到 Object 后，会尝试把它转换成目标所需的 String；目标返回基本类型 int 后，再装箱成 Integer。这不是字符串化：传入的对象必须实际是 String，否则运行时转换仍会失败。

为什么 invokeExact 还要再次对齐

asType 返回的新句柄虽然报告的是 (Object)Integer，但调用点依然要用同样的静态类型。把结果接到 Object 变量，或把参数声明为 String，都会改变编译器发出的调用点描述。

Object input = "method-handle";
Integer result = (Integer) adapted.invokeExact(input);
System.out.println(result); // 13

这段代码的关键不是强制转换写法，而是调用点的参数静态类型。若把 input 声明成 String，即使运行时对象没有变化，invokeExact 也不再是 (Object)Integer 的精确调用。

三类失败要分开看

返回值类型写错

将目标签名适配到 (Object)Long 并不等于把 int 自动变成长整型包装对象；如果转换规则不成立，asType 会抛出 WrongMethodTypeException。

参数对象不是 String

Object input = 13 时，适配句柄仍会按目标需要尝试获得 String。这属于调用时的对象类型问题，不是把数字转成文本的格式化操作。

参数个数发生变化

asType 不是参数插入或删除工具。调用侧和目标侧的参数数量不匹配时，应回到 MethodHandles.insertArguments、dropArguments 等专用变换，别继续堆叠 asType。

用一个最小回归检查把边界锁住

1. 先断言 target.type().equals(MethodType.methodType(int.class, String.class))，确认查找到了预期方法。
2. 再断言 adapted.type().equals(MethodType.methodType(Integer.class, Object.class))，确认适配句柄的公开签名已经变更。
3. 使用实际的 String 对象调用一次 adapted.invokeExact，核对返回值为 Integer。
4. 为不可转换返回类型、非 String 参数和错误参数个数各保留一个失败测试，并记录异常发生在创建适配句柄还是调用阶段。

相关问题

asType 和 invoke 有什么关系？

普通 invoke 在调用点类型不同且转换可行时，行为上会尝试进行类似 asType 的适配；invokeExact 则不做这种宽松匹配。

什么时候应该直接保留原始句柄？

如果调用方已经使用 (String)int 的精确签名，直接复用原始句柄更清楚，也少一次适配层。只有跨边界调用确实需要另一套签名时，才创建并缓存适配句柄。

实战中把 type()、目标 MethodType 和调用点静态类型放在同一张检查单里，通常比盯着异常堆栈更快。适配成功不代表任意对象都能进入目标方法；它只说明请求的签名在 Java 的转换规则内可建立。