建设 网站协议,广告设计公司vi,wordpress搜索时间间隔,在wordpress上添加播放视频教程java虚拟内存扩展我一直关注Java 8 Lambda表达式项目的发展已经有一段时间了#xff0c;我对其当前的进展状态感到非常兴奋。 我发现的最新“易于理解”的演示文稿是这样的#xff1a; 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的JCG合作伙伴 Lukas Eder的Java 8虚拟扩展方法 位于JAVASQL和JOOQ博客上。 相关文章 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.htmljava虚拟内存扩展
