我一直关注Java 8 Lambda表达式项目的发展已经有一段时间了,我对其当前的进展状态感到非常兴奋。 我发现的最新“易于理解”的演示文稿是这样的:
http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf
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,SQL和JOOQ博客上的JCG合作伙伴 Lukas Eder提供的Java 8虚拟扩展方法 。
相关文章 :
- Java Lambda语法替代
- Java SE 7、8、9 –推进Java
- Java 7功能概述
- 在Java 7中处理文件
- 具有Java 7中自动资源管理功能的GC
- Java 7:尝试资源
翻译自: https://www.javacodegeeks.com/2011/12/java-8-virtual-extension-methods.html