Goetz開始談論Java 8處于“成熟階段”，但尚未發布或準備交付。 他說，他希望Java 8和Lambda能夠在明年這個時候上市。 Goetz說，“您可以編寫任何值得使用Java編寫的程序”，但是Java 8將使編寫此程序變得更加容易。 他的幻燈片“現代化Java”談到Java SE 8“現代化Java語言”和“現代化Java庫”。 他在幻燈片上的最后一句話說：“這也許是Java編程模型有史以來最大的升級 。” 這就是我的感覺，這就是為什么我對這次演講沒有得到更好的參與感到驚訝的部分原因。
Goetz表示lambda表達式是“匿名方法”。 除了名稱之外，它具有方法具有的所有內容（參數列表，返回類型和主體）。 它允許您將代碼視為數據 。 方法參考引用現有方法。 Goetz重申，由于添加了lambda表達式，將導致向編寫和使用庫的巨大根本轉變。
Goetz指出，Java于1995年問世時，大多數語言都沒有閉包，但是如今，除Java之外的大多數語言都具有閉包。 然后，他在名為“ Java的封閉-漫長而曲折的道路”的幻燈片中總結了Java封閉的一些歷史。 他引用Odersky的年代和Wadler 1997年的“比薩”（1997年），Java 1.1中的內部類（1997），以及2006 - 2008年“ 轟轟烈烈的社會辯論關于關閉 ”（包括BGGA和CICE ）。 Lambda項目成立于2009年12月，相關的JSR 335于2010年11月提交。今天，它“相當接近完成”。
Goetz指出，for循環“對于當今的硬件已過度指定”，同時描述了與我們今天經常使用的“外部迭代”的使用相關的“意外復雜性”。 我同意他的觀點，即“ foreach循環隱藏了客戶端和庫之間的復雜交互”。
lambda表達式的目標允許將“如何”從客戶端移至庫。 Goetz強調說，這不僅僅是語法上的更改，因為該庫受lambda表達式控制，并且是內部迭代 。 Goetz表示：“客戶處理“什么”，而圖書館處理“如何”，那是一件好事。” 他補充說，lambda表達式對我們的編碼方式尤其是對我們開發庫的方式具有深遠的影響。
Goetz討論了使用新的Java接口默認實現機制將新的forEach(Block)方法添加到集合中的方法。 Goetz區分了Java一直具有類型的多重繼承（可以實現多個接口），現在（Java 8）將具有行為的多重繼承（可用于接口的默認方法實現），但仍然不會具有狀態的多重繼承（他將其描述為最危險的）。 戈茨有一張幻燈片專門用來解釋當您從多重繼承中取出日期（狀態）時為什么“ 鉆石容易”。
Goetz的幻燈片很好，總結了“默認方法-繼承規則”。 這張幻燈片介紹了三個規則。 他指出，“如果無法通過規則解決默認問題，則子類必須實現它。” Goetz指出，接口可以提供“弱”的默認實現，而子類可以提供更好的實現。
接口上默認方法的另一個優點是，默認實現可以為可選方法引發異常（例如UnsupportedOperationException ），這樣，未實現可選行為的子類就無需執行其他任何操作。 Goetz還展示了Lambda表達式如何使Comparator可以添加reverse（）和compose（）方法。
Goetz展示了一些代碼示例，這些示例說明了lambda表達式允許使用“更干凈”和“更自然”的表示形式。 用他的話說，由于lambda表達式驅動的操作具有可組合性，因此“代碼讀起來就像問題聲明”。 客戶端中也沒有任何可變狀態。
我計劃將來在Goetz的一張幻燈片中引用一句話：“懶惰可以更有效。” 這樣的上下文是，如果您不打算使用所有結果，那么懶惰會更有效，因為一旦確定了匹配項，您就可以停止尋找。 流操作要么是中間的（延遲），要么是最終的（自然而然）。
Stream是一種引入的抽象，允許添加批量操作，并且“表示值的流”。 Goetz的項目符號警告說，Stream是“不是數據結構”并且“不存儲值”。 這樣做的目的是避免在設置過程中產生噪音，并嘗試更加“流暢”。
格茨表示，“ Java的朋友之一一直是庫。” 他談到了lambda表達式如何在Java庫中實現更大的并行度。 Goetz表示fork-join功能強大，但不一定易于使用。 Goetz強調：“編寫串行代碼很容易； 編寫并行代碼真是麻煩。” Lambda表達式仍然需要并行性才能明確，但對于lambda表達式及其對庫的影響應不加干擾。
為了強調Project Lambda對庫中并行性的影響，Goetz展示了一個令人痛苦的幻燈片，其中介紹了今天如何使用fork-join與集合進行并行求和，然后另一個幻燈片顯示了lambda表達式的使用更加簡單。 重點是：帶有lambda表達式的代碼要少得多，從而使業務邏輯在整個代碼中所占的比例更大。
格茨（Goetz）將Spliterator稱為“ Iterator的并行模擬”。 拆分器的規定行為可用于任何知道如何拆分自身的對象（ Spliterable ）。
幻燈片“ Lambdas支持更好的API”使lambda表達式對標準Java API產生了強大而受歡迎的效果。 他強調，“對API的關鍵影響是可組合性 。
Goetz表示，出于多種原因（例如成本更低，風險更低等），我們通常更喜歡通過庫而不是語言語法來發展編程模型。他在總結演講時指出，時代已經改變，而Java不再支持閉包。
一位與會者詢問為什么lambda表達式方法支持是在集合上而不是迭代器上。 Goetz表示，盡管C＃確實從迭代器方法開始使用它，但他的團隊發現，對于開發人員而言，在集合上而不是在迭代器上使用方法的混亂程度降低了。
在回答另一個問題時，Goetz表示，由于其復雜性，尚無法對lambda表達式進行反思。 為了回答另一個問題，Goetz表示，lambda表達式支持是使用invokedynamic和方法handle構建的。 這是使lambda表達式“易于編程”和“快速”的一部分工作。
另一個問題引起了Goetz的一個非常有趣的回答，其中Goetz解釋說，集合本身內部迭代的可用性意味著更少的人（庫開發人員而不是最終用戶開發人員）將會遇到迭代復雜性。 Goetz鼓勵與會者運行當前可用的Java 8 drop，以幫助確定Lambda表達式是否得到正確處理。 Goetz表示：“我們從社區中獲得的最有價值的貢獻是人們說，'我嘗試了一下，發現了這個bug。”
Goetz在開始此演示時指出，這是在以前的JavaOne會議和其他有關lambda狀態的會議中的一連串演講。 但是，與此不同的是，Lambda項目“幾乎在那兒”，考慮到這一點，似乎語法和概念在很大程度上已經就位。 歡迎對API和語法進行這種明顯的固化，并且此演示文稿滿足了我對此的很高期望。
別忘了分享！
參考： JavaOne 2012：Lambda之路，來自JCG合作伙伴 Dustin Marx， 來自Inspired by Actual Events博客。
翻譯自: https://www.javacodegeeks.com/2012/10/javaone-2012-road-to-lambda.html
