我們在《2018 編程語言流行度大調查》中談到，在用戶喜愛和關注的編程語言中，Java獨領風騷。其中，Java 9關注度不斷上升，62% 的人希望在 2018 年更多地關注 Java 9，此外有三分之一的參與者表示對即將到來的Java 10 和 11版本很感興趣。
在過去的一年中Java經歷了一段時間的動蕩，今年Java又有什么新進展呢?本文讓我們一起來看看Java的狀況吧。
2017年是Java界動蕩的一年。期待已久的Java 9帶來了許多的變化和有趣的新功能，同時Oracle也宣布了JDK新的發布時間表。而這一切只是個開始。過去開發人員常常抱怨Java的發展速度不夠快。我認為這些抱怨將在不久的將來消失，甚至有可能帶來意外的驚喜。
從2018年開始，JDK建立了全新的發布時間表。以前一次大的版本升級需要等好幾年，現在則縮短為每隔6個月發布一次小版本。繼2017年9月Java 9發布之后，Java 10將在2018年3月發布，以及之后更多的新版本都將很快到來。
歡迎工作一到五年的Java工程師朋友們加入Java技術交流：611481448
群內提供mf的Java架構學習資料(里面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料)合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰!趁年輕，使勁拼，給未來的自己一個交代!
企業技術棧概覽
大多數企業項目不僅使用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 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界內將出現全新的活力。另一方面，那些若干年才更新一次應用程序的各大公司要做好心理準備哦。
