我有一个单元测试,可以搜索我的项目并找到特定接口的所有实现。然后对于作为内部类的每个实现,我断言它不捕获外部类。
我使用Reflections库来执行此操作,它确实有效,但现在我需要测试另一个接口,其中许多实现都是 lambdas。遗憾的是,Reflection找不到接口的 lambda 实现。
我可以使用另一种适用于 lambda 的解决方案吗?
我有一个单元测试,可以搜索我的项目并找到特定接口的所有实现。然后对于作为内部类的每个实现,我断言它不捕获外部类。
我使用Reflections库来执行此操作,它确实有效,但现在我需要测试另一个接口,其中许多实现都是 lambdas。遗憾的是,Reflection找不到接口的 lambda 实现。
我可以使用另一种适用于 lambda 的解决方案吗?
反射找不到接口的 lambda 实现。我可以使用另一种适用于 lambda 的解决方案吗?
没有可靠的方法来使用反射识别功能接口的实例,而且看起来永远不会有。请参阅对 openjdk 请求的此响应,以引入编译器选项以使用 Signature Attribute 存储有关 lambda 表达式的泛型类型信息:
我明白为什么人们希望反射在 lambda 实例上工作,但这不是反射的工作方式——反射反映在类上,而不是实例上。 当前的翻译策略恰好是这样一种策略,如果该属性存在,将使反射能够“意外地工作”以提供通用信息,但这会 改变,此时任何基于反射的策略都会崩溃(此时人们指责破坏他们本应从未使用过的代码。)
类似地,请参阅这篇 SO 帖子中的这些评论(也来自 Brian Goetz)为什么使用 invokedynamic 调用 Java 8 lambda?
运行时实现可以自由地动态选择策略来评估 lambda 表达式。运行时实现选择隐藏在用于 lambda 构造的标准化(即平台规范的一部分)API 后面,因此静态编译器可以发出对该 API 的调用,而JRE 实现可以选择它们首选的实现策略。
底线是您无法知道 lambda 表达式在运行时将如何处理。