動蕩的 Java 今年將有哪些新變化？
在過去的一年中Java經歷了一段時間的動蕩，今年Java又有什麽新進展呢？本文讓我們一起來看看Java的狀況吧。
以下為譯文：
2017年是Java界最動蕩的一年。期待已久的Java 9帶來了許多的變化和有趣的新功能，同時Oracle也宣布了JDK最新的發布時間表。而這一切只是個開始。過去開發人員常常抱怨Java的發展速度不夠快。我認為這些抱怨將在不久的將來消失，甚至有可能帶來意外的驚喜。
從2018年開始，JDK建立了全新的發布時間表。以前一次大的版本升級需要等好幾年，現在則縮短為每隔6個月發布一次小版本。繼2017年9月Java 9發布之後，Java 10將在2018年3月發布，以及之後更多的新版本都將很快到來。
企業技術棧概覽
大多數企業項目不僅使用JDK，還依賴一系列的企業級函數庫，如Spring Boot、Java EE等，而這些函數庫也將在接下來幾個月中得到升級。我將在本文中重點討論JDK，但是首先讓我們來看看Java界中兩個主要的企業技術棧將有哪些變化。
Spring開發團隊正在努力開發Spring Boot 2，並在今年1月份發布了第一個RC版本。該團隊並沒有在API方面做出重大的變化，也不打算在最終版本發布之前添加任何新功能。所以，如果你的項目中用到了Spring Boot，那麽最好現在仔細研究新版本，並開始計劃現有Spring Boot應用程序的更新。
在2017年年底，Oracle將Java EE標準移交給了由Eclipse基金會管理的EE4J項目。正如大家所料，移交這樣的一個大項目不可能在幾天內完成，其中有很多組織和技術方面的工作需要完成。Java EE需要一個新名字並建立全新的開發流程。另一方面，保存在各種bug跟蹤工具中的源代碼和二進制文件的移交仍在進行中。開發者還需要等待很長一段時間，才能看到此次移交帶來的效果，以及更強大的社區參與。
縮短JDK的發布和支持周期
Oracle去年宣布將在2018年內發布兩個新的JDK版本。以往Oracle一貫秉承緩慢的版本發布節奏，每隔幾年才發布一個主版本，其中包含大量的變化，從今年起將改為每6個月發布一個較小的版本。這一變化可以加速Java平臺的創新，還可以降低Java更新帶來的風險。而Java開發人員可以更加容易地熟悉小版本的最新變化，並將其應用到項目中。
我認為這對Java界是個非常積極的改變，它將為Java語言的開發增添新動力，JDK團隊也可以更快地適應和創新。
JDK 10帶來的變化和新功能
由於發布周期較短，Java 10只包含少量的變化。請參照OpenJDK網站公布的有關JDK 10的最新消息（http://openjdk.java.net/projects/jdk/10/），其中包含12個JEP（JDK Enhancement Proposal，JDK改進提案）。
其中最值得一提的變化是局部變量的類型推斷（JEP 286，http://openjdk.java.net/jeps/286）。其次你應該了解下新增的基於時間的版本命名方式（JEP 322，http://openjdk.java.net/jeps/322），以及G1（或稱Garbage First垃圾收集器）開始支持並行Full GC（JEP 307，http://openjdk.java.net/jeps/307）。
類型推斷
JDK 10終於引入了類型推斷。許多其他靜態類型語言很早就已經支持這個功能了，眾多Java開發人員一直希望引入這項功能。
JEP 286引入了關鍵字var，簡化了局部變量的聲明，並由編譯器根據初始化代碼推斷變量的類型。以往我們必須寫：
List<String> paramNames = List.of("host.name", "host.port");
Configuration config = initializeConfig(paramNames);
現在可以簡化為：
var paramNames = List.of("host.name", "host.port");
var config = initializeConfig(paramNames);
以上代碼中，關鍵字var替代了冗長的變量聲明。這可以增加代碼的閱讀性，特別在代碼有合理的變量命名規則，並且變量僅在聲明後使用幾次的情況下尤為明顯。
如果想更深入地了解JEP 286以及使用方法，可以參照Nicolai Parlog的這篇文章：https://blog.codefx.org/java/java-10-var-type-inference/。
基於時間的版本命名方式
從Java 10開始，Java的版本號格式將發生變化，以更好地支持基於時間的發布方式。
新的發布方式帶來的最大難點在於：版本的實際內容可能發生變化。由於開始時唯一可以確定的只有新版本的發布時間，所以如果新功能的開發時間比預期長，無法在新版本發布時完成，就不能進入新版本。因此版本號需要以時間點為準，而非版本內包含的變更內容。
JEP 322定義的版本號格式為：$ 功能號.$ 臨時號.$ 更新號.$ 補丁號，具體使用方法如下：
開發團隊將在每6個月發布一個新功能版本，並將版本號的“$ 功能號”加1。
2018年3月發布的版本為JDK 10，那麽9月份的新版本就是JDK 11。開發團隊在JEP 223中表示，他們希望每次新功能發布可以至少包含一到兩個重要功能。
“$ 臨時號”可以靈活使用，目前以6個月為期的發布方式中並沒有用到此項，所以到目前為止，這個數字始終是0。
開發團隊還將在功能發布之間穿插小的升級，這種升級不會包含不兼容的改動。他們可以在功能發布後的1個月或3個月，發布一次小的升級，屆時可以將“$ 更新號”加1。
G1的並行Full GC
對於大多數開發者來說，這只是個很小的變化。有的應用程序甚至都不會註意到這個變化。
JDK 9中G1成了默認的垃圾回收器。G1的設計目的旨在避免全面的垃圾回收，但是並不代表這種現象永遠不會發生。不幸的是，G1在執行全面回收時僅使用了單線程的“標記-清理-壓縮”算法，與之前的並行回收器相比這可能導致性能的下降。
JEP 307實現了這一算法的多線程版，從而解決了該問題。從JDK 10開始，它將使用與Young GC和Mixed GC同樣多的線程數。
因此，如果應用程序需要強制垃圾回收器執行全面的回收，那麽JDK 10可以提高效率。
有關JDK 11的計劃
JDK 10還沒有正式發布，而距離JDK 11的發布只有7個月了。所以，其開發團隊已經制定了幾個JEP的計劃，請參照2018年第二次新功能發布的信息：http://openjdk.java.net/projects/jdk/11/。
除了刪除廢棄的Java EE和CORBA模型（JEP 320）、以及引入新的垃圾回收器（JEP 318）之外，JDK 11還有可能引入動態的類文件常量（JEP 309），以及在隱含類型的匿名表達式中支持關鍵字var（JEP 323）。
JDK 11目前的範圍體現了縮短發布周期所帶來的優勢，JEP 309和310引入了新功能，而其他兩個JEP則負責通過叠代方法改進已有功能。
2017年9月JDK 9發布的時候，Java EE和CORBA模塊就被廢棄了。一年以後，隨著JDK 11的發布，JEP 320將把它們從JDK中刪除。所以它們不會在Java中逗留太久，很快就要計劃刪除了。
繼JEP 286在JDK 10中引入局部變量的類型推斷後，JEP 323將進一步提升這一功能。將來我們可以看到更多關於這方面的改進。發布周期縮短後，團隊可以分步在一次或多次功能發布中完成一個大功能，從而降低發布的難度。
縮短支持周期需要快速適應
Oracle在推出新的發布方式的同時，也改變了他們的支持方式。這個新的方式對短期發布和長期發布的支持所有不同。
短期發布（如Java 9和10等），相關的面向公眾的支持會在下個版本發布時終止。因此Java 9的支持將於2018年3月停止，而2018年9月後Java 10也無法再獲得支持。
Java 11是一次長期發布。Oracle對這類發布的支持期限更長，但是到目前為止，他們還沒有宣布對Java 11的支持會持續到什麽時候。
應用程序開發者需要決定是否要每6個月更新一次Java版本，還是選擇多等幾年使用長期的發布版本。另外，Oracle鼓勵所有人使用Java SE的高級產品，它們的每個長期發布版都包含至少5年的支持。
總結
過去，大量開發者抱怨Java的升級太慢，2018年後這種情況將有所改善。全新的、6個月為期的發布周期和相應的支持模型，可以加速已有應用程序的升級，並定期引入新功能。加上Java EE和Spring等已有框架的提升，Java界內將出現全新的活力。另一方面，那些若幹年才更新一次應用程序的各大公司要做好心理準備哦。
喜歡小編輕輕點個關註吧！
動蕩的 Java 今年將有哪些新變化？