jdk 9和jdk8

眾所周知，冬天（尤其是圣誕節前的時間）是做夢的合適時機，希望有一個夢想似乎可以觸及的時刻。 當孩子們和大人在紙上或在他們對圣誕老人的虛構或真實信件中寫下自己的夢想時，希望他們的夢想將成為現實。 這很容易引起人們的注意，因為甚至在12月的第一天，OpenJDK背后的人們在發布更新的JEP列表時也表達了對Java的愿望。 等一下，不要激動，只是還沒有......因為我們知道苦澀，他們將有可能成為現實的地方在2016年年初或至少是這樣的計劃，歷史向我們展示了什么堅持一個計劃手段。

當然，上述列表中包含JEP，但這并不意味著最終版本將包含JEP，正如JEP 流程圖清楚地說明了這一點，但是為了避免冬天的妖精尾巴，我們將遍歷列表并提供一個簡要說明每個項目的預期目的是什么。

免責聲明： JEP列表是一個移動的目標，因為本文發布后，該列表至少更改了一次。

那些幸運的不是那么好的人，似乎圣誕老人懲罰了您，并且您很高興使用Java的進程api，并且當然滿足了他的限制。 在JDK 7中進行了更改之后，當前的JEP進一步改進了該API，并使我們能夠：

• 獲取當前Java虛擬機的pid（或等效值）以及使用現有API創建的進程的pid
• 獲取/設置當前Java虛擬機的進程名稱以及使用現有API創建的進程（如果可能）
• 枚舉系統上的Java虛擬機和進程。 有關每個進程的信息可能包括其pid，名稱，狀態以及可能的資源使用情況
• 處理流程樹，特別是一些破壞流程樹的方法
• 處理數百個子流程，也許復用輸出或錯誤流，以避免為每個子流程創建線程

我不了解您，但我肯定可以找到至少兩個可以充分利用其中某些功能的場景，所以請稍等。

前幾天，我有幸與Peter Lawrey一起參加性能研討會，而Java性能調優的經驗法則之一是：應用程序的并發最少，性能更高。 有了這一改進，性能調整的規則可能需要找到另一個經驗法則，因為使用此JEP實施的目標是在Java中使用監視器的延遲。 更準確地說，目標是：

• 字段重新排序和緩存行對齊
• 加快PlatformEvent::unpark()
• 快速Java監視器輸入操作
• 快速Java監視器退出操作
• 快速Java監視器notify / notifyAll操作
• 自適應旋轉改進和SPARC上的SpinPause

標題說明了一切。 如果您使用的是企業級應用程序，則必須至少處理一次或兩次gc日志，并且我想在查看信息量及其顯示方式時至少要引起注意（如果不是全部）。 好吧，如果您足夠“幸運”，那么您可能會在JVM版本之間進行遷移，然后當您意識到為先前版本構建的解析器遇到了與當前版本有關的問題時，肯定希望/需要再引起兩個注意。 JVM日志記錄。 我想我可以繼續說明為什么不好，但是讓我們集中精力進行改進，因此希望在下一個發行版中，我們有理由抱怨說，情況會好一些。

gc日志記錄似乎試圖與我們可能也會使用的其他日志記錄框架（如log4j）保持一致。 因此，從記錄的信息的嚴重性（錯誤，警告，信息，調試，跟蹤）的角度來看，它將在不同的級別上工作，其性能目標是錯誤和警告不會對生產環境產生任何性能影響，適合生產環境的信息，而調試和跟蹤沒有任何性能要求。 默認的日志行如下所示：

[gc][info][6.456s] Old collection complete

為了確保靈活性，日志記錄機制將可通過JVM參數進行調整，目的是對它們采用統一的方法。 為了向后兼容，將盡可能將現有的JVM標志映射到新標志。

To be as suitable as possible for realtime applications, the logging can be manipulated through jcmd command or MBeans.

該JEP唯一可能也是最大的缺點是，它的目標只是提供日志記錄機制，并不一定意味著日志也會有所改進。 為了擁有美麗的原木，我們夢of以求的是也許我們需要再等一些。

您可能知道，Java平臺使用JIT編譯器來確保編寫的應用程序的最佳運行。 現有的兩個直接稱為C1和C2的編譯器分別對應于client（-client選項）和服務器端應用程序（-server選項）。 該JEP的明確目標是提高這些編譯器的可管理性：

• 對JVM編譯器（C1和C2）的細粒度和方法上下文相關的控制。
• 在運行時更改JVM編譯器控制選項的能力。
• 性能不會下降。

JVM的性能似乎是將來的Java版本中的目標，因為當前的JEP旨在優化代碼緩存。 目標是：

• 單獨的非方法，概要文件和非概要文件代碼
• 由于專門的迭代器跳過了非方法代碼，因此掃描時間更短
• 縮短一些編譯密集型基準測試的執行時間
• 更好地控制JVM內存占用
• 減少高度優化的代碼的碎片
• 改進代碼局部性，因為很可能會及時關閉相同類型的代碼
  • 更好的iTLB和iCache行為
• 為將來的擴展奠定基礎
  • 改進了對異構代碼的管理；

從我的角度來看，前兩個已聲明的目標非常令人興奮，有了這兩個目標，只需跳過非方法區域，即在整個JVM運行時中應該存在的區域，可以大大提高代碼緩存的掃描時間。

這種改進的出現并不令人感到意外，但對我而言，它并沒有在JDK中出現就變得令人驚訝，因為JSON取代XML成為了Web的“通用語言”，不僅適用于響應式JS前端-end，但也用于構造NoSQL數據庫中的數據。 該JEP聲明的目標是：

• JSON RFC7159的解析和生成。
• 功能滿足使用JSON的Java開發人員的需求。
• 解析API，可以選擇解析令牌流，事件（包括文檔層次結構上下文）流或JSON文檔和數據流的不可變樹表示視圖。
• 緊湊的概要文件和Java ME的有用API子集。
• 使用Builder風格的API構建不可變的值樹。
• JSON數據流輸出和JSON“文字”的生成器樣式API。
• 轉換器API，將現有的值樹作為輸入并生成新的值樹作為結果。

同樣，其目的是與JSR 353保持一致。 即使將來的JSON與現有的庫相比功能有限，它也具有集成和使用JDK 8中新添加的功能（如流和lambda）的競爭優勢。

sjavac是已經著名的javac的包裝，該包裝旨在在編譯大型項目時提高性能。 與當前階段一樣，該項目具有穩定性和可移植性問題，主要目標是修復給定的問題，并可能使其成為JDK項目的默認構建工具。 擴展的目標是使該工具可用于除JDK以外的項目，并可能與現有工具鏈集成。

朝著項目拼圖的實施方向邁出的第一步，旨在將源代碼重新組織為模塊，從而增強了用于構建模塊并尊重模塊邊界的構建工具。

該JEP的目標是促進使大型代碼庫清除掉棉絨警告。 使用@SuppressWarnings批注無法抑制導入時的過時警告，這與在代碼中使用過時的成員不同。 在像JDK這樣的大型代碼庫中，通常必須在一段時間內支持不推薦使用的功能，并且如果故意和禁止使用不推薦使用的構造，則僅導入不推薦使用的構造并不能作為警告消息的依據。

由于JDK 9的午餐日期是2016年初，因此該JEP非常適合一年中的那個時候以及相應的瑣事：Spring大掃除。 它的主要目標是至少在平臺的基本軟件包下，在javac的lint選項（-Xlint：all）下進行干凈的編譯。

從JDK 7開始，Project coin的目標是在Java語言中引入一些語法糖，以在成熟的平臺上引入一些新功能。 即使它沒有對語言的性能進行任何改進，它也提高了代碼的可讀性，因此，在我看來，它為軟件項目中最重要的資產之一帶來了加分，在我看來，這是一個更具可讀性的代碼庫。

該JEP針對四個變化：

在私有實例方法上允許@SafeVargs 。

允許在try-with-resources語句中將有效最終變量用作資源 。

如果推斷類型的參數類型是可表示的，則允許菱形具有內部類 。

從Java SE 8開始，從合法標識符名稱集中刪除下劃線。

隨著Java 8發行版中已棄用的JVM標志的刪除，Spring清理工作繼續進行，因此，在9發行版中，將不再支持以下選項：

DefNew + CMS : -XX:-UseParNewGC -XX:+UseConcMarkSweepGC ParNew + SerialOld : -XX:+UseParNewGCParNew + iCMS : -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC ParNew + iCMS : -XincgcDefNew + iCMS : -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC -XX:-UseParNewGC CMS foreground : -XX:+UseCMSCompactAtFullCollection CMS foreground : -XX:+CMSFullGCsBeforeCompactionCMS foreground : -XX:+UseCMSCollectionPassing

該JEP旨在Fix javac以正確地接受和拒絕程序，而不管import語句的順序如何，并extends和implements子句。

已經設計了越來越多的使用UDP傳輸的應用層協議，特別是諸如會話啟動協議（SIP）和電子游戲協議之類的協議使安全性問題比以往任何時候都高，尤其是因為TLS僅可用于諸如TCP之類的可靠協議上。 當前的JEP打算通過定義用于數據報傳輸層安全性（DTLS）版本1.0（ RFC 4347 ）和1.2（ RFC 6347 ）的API來填補這一空白。

作為JEP 201的后續步驟，其目的是重組JDK和運行時環境以容納模塊并提高性能，安全性和可維護性。 定義新的URI方案，以命名存儲在運行時映像中的模塊，類和資源，而無需透露映像的內部結構或格式。 根據需要修改現有規格以適應這些更改。

隨著HTML標準版本達到版本5，JDK的javadoc頁面也需要跟上步伐，因此需要從HTML 4.01升級。

在JRE啟動時，請刪除請求的功能（通過使用-version :），該功能不是正在啟動的JRE的JRE版本。 刪除將逐步完成：版本9中將發出警告，而Java 10可能會引發錯誤。

這是為JDK 9準備的增強功能列表的當前形式，老實說，當我初次查看它時，我有些沮喪，但是在閱讀了更多內容后，我感到非常興奮，因為Java似乎尚未開始進行另一次冒險，他們需要獲得所有可能的幫助。 因此，如果您想參與其中（請做！），那么java出現系列的后續博客文章將向您介紹如何參與。 想象一下它就像環的同伴，但是冒險的目標是建造Java而不破壞環……弗羅多先生可能是誰？

翻譯自: https://www.javacodegeeks.com/2014/12/jdk-9-a-letter-to-santa.html

jdk 9和jdk8

總結

以上是生活随笔為你收集整理的jdk 9和jdk8_JDK 9 –给圣诞老人的信？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。