我一直关注Java 8 Lambda表达式项目的发展已经有一段时间了，我对其当前的进展状态感到非常兴奋。 我发现的最新“易于理解”的演示文稿是这样的：
http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf

现在，作为API设计师，我对虚拟扩展方法的概念特别感兴趣，并且我想知道是否也考虑引入“最终”扩展方法而不是“默认”扩展方法。 例如：

interface A {void a();void b() default { System.out.println("b"); };void c() final { System.out.println("c"); };}

当实现上述接口A时，…

• 还必须实现a（）
• 可以实现/重写b（）
• 无法覆盖c（）

优点：

• API设计人员可以更轻松地创建方便的方法，而不必冒“非法”覆盖默认实现的风险冒用客户代码。 这是“决赛”的主要目的之一。
• Lambda表达式不必仅限于纯“功能接口”（单方法接口），因为如果功能接口也具有任何数量的最终扩展方法，则其仍将是“功能”。 例如，如果b（）被删除或b（）也被最终确定，则上述接口A将成为功能接口。
• 扩展方法将具有与常规方法相同的更多功能，而常规方法也可以是最终方法。 我想对于反射API和JVM来说 ，这是一个加号。
• 无论如何，JVM都会进行修改以支持扩展方法。 Java 8的动力也可以用于此功能，即现在正是考虑这一点的合适时机

缺点：

• 在“钻石接口继承 ”的情况下，一个类可以继承多个冲突的最终方法实现。 这可能会导致现有代码中出现新的编译错误。 我想缺乏向后兼容性是最大的缺点。

与多重继承本身一样，谨慎的API设计人员可以在使用最终扩展方法时进一步改善其API，而不太谨慎的API设计人员可能会破坏客户端代码。 但是这个
以前的“ final”用法也是这种情况，因此我认为最终扩展方法将是对Java 8的很好补充。

请在此处查看完整的邮件和lambda-dev邮件列表中的后续邮件：

http://mail.openjdk.java.net/pipermail/lambda-dev/2011-December/004426.html

参考：来自 Java的JCG合作伙伴 Lukas Eder的Java 8虚拟扩展方法 ，位于JAVA，SQL和JOOQ博客上。

相关文章 ：

• Java Lambda语法替代
• Java SE 7、8、9 –推动Java前进
• Java 7功能概述
• 在Java 7中处理文件
• 具有Java 7中自动资源管理功能的GC
• Java 7：尝试资源