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

當(dāng)然，上述列表中包含JEP，并不意味著最終版本將包含JEP，因為JEP 流程圖清楚地說明了這一點，但是為了避免寒冬，我們將遍歷列表并提供一個JEP。簡要說明每個項目的預(yù)期目的是什么。

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

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

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

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

前幾天，我有幸與Peter Lawrey一起參加性能研討會，而Java性能調(diào)優(yōu)的經(jīng)驗法則之一是：應(yīng)用程序的并發(fā)最少，性能更高。 有了這項改進(jìn)，性能調(diào)整的規(guī)則可能需要找到另一個經(jīng)驗法則，因為使用此JEP實施的目標(biāo)是在Java中使用監(jiān)視器的延遲。 更準(zhǔn)確地說，目標(biāo)是：

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

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

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

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

為了確保靈活性，日志記錄機制將可通過JVM參數(shù)進(jìn)行調(diào)整，目的是對它們采用統(tǒng)一的方法。 為了向后兼容，將盡可能將現(xiàn)有的JVM標(biāo)志映射到新標(biāo)志。

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

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

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

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

JVM的性能似乎是將來的Java版本的目標(biāo)，因為當(dāng)前的JEP旨在優(yōu)化代碼緩存。 目標(biāo)是：

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

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

這種改進(jìn)的出現(xiàn)并不令人驚訝，但對我而言，它并沒有在JDK中出現(xiàn)更令人驚訝，因為JSON取代XML成為了Web的“通用語言”，不僅適用于響應(yīng)式JS前端-end，但也用于構(gòu)造NoSQL數(shù)據(jù)庫中的數(shù)據(jù)。 該JEP聲明的目標(biāo)是：

• JSON RFC7159的解析和生成。
• 功能滿足使用JSON的Java開發(fā)人員的需求。
• 解析API，允許選擇解析令牌流，事件（包括文檔層次結(jié)構(gòu)上下文）流或JSON文檔和數(shù)據(jù)流的不可變樹表示視圖。
• 緊湊的概要文件和Java ME的有用API子集。
• 使用構(gòu)建器風(fēng)格的API進(jìn)行不可變的價值樹構(gòu)造。
• JSON數(shù)據(jù)流輸出和JSON“文字”的生成器樣式API。
• 轉(zhuǎn)換器API，將現(xiàn)有的值樹作為輸入并生成新的值樹作為結(jié)果。

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

sjavac是已經(jīng)著名的javac的包裝，該包裝旨在在編譯大型項目時提高性能。 與當(dāng)前階段一樣，該項目存在穩(wěn)定性和可移植性問題，主要目標(biāo)是修復(fù)給定的問題，并使其有可能成為JDK項目的默認(rèn)構(gòu)建工具。 擴展的目標(biāo)是使該工具可用于除JDK以外的項目，并可能與現(xiàn)有工具鏈集成。

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

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

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

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

該JEP針對四個變化：

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

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

如果推斷類型的參數(shù)類型是可表示的，則允許菱形具有內(nèi)部類 。

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

隨著Java 8發(fā)行版中棄用的JVM標(biāo)志的刪除，Spring清理工作繼續(xù)進(jìn)行，因此，在9發(fā)行版中，不再支持以下選項：

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子句。

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

作為JEP 201的后續(xù)步驟，旨在重組JDK和運行時環(huán)境以容納模塊并提高性能，安全性和可維護(hù)性。 定義一個新的URI方案，以命名運行時映像中存儲的模塊，類和資源，而無需透露映像的內(nèi)部結(jié)構(gòu)或格式。 根據(jù)需要修改現(xiàn)有規(guī)格以適應(yīng)這些更改。

隨著HTML標(biāo)準(zhǔn)版本達(dá)到版本5，JDK的javadoc頁面也需要跟上步伐，因此需要從HTML 4.01升級。

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

這是為JDK 9準(zhǔn)備的增強功能列表的當(dāng)前形式，老實說，當(dāng)我初次查看它時，我有些沮喪，但是在閱讀了更多內(nèi)容后，我感到非常興奮，因為Java似乎尚未開始進(jìn)行另一次冒險，他們需要獲得的所有幫助。 因此，如果您想?yún)⑴c進(jìn)來（請做！），java advent系列的后續(xù)博客文章將向您介紹如何參與。 想象一下它就像環(huán)上的同伴船，但是冒險的目標(biāo)是建造Java而不破壞環(huán)……弗羅多先生可能是誰？

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。