我一直關注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，SQL和JOOQ博客上的JCG合作伙伴 Lukas Eder提供的Java 8虛擬擴展方法 。

相關文章 ：

• Java Lambda語法替代
• Java SE 7、8、9 –推進Java
• Java 7功能概述
• 在Java 7中處理文件
• 具有Java 7中自動資源管理功能的GC
• Java 7：嘗試資源