趨勢報告框架
第⼀部分：Java的技術采⽤⽣命周期
這部分采⽤與英⽂站同樣的標准划分：
創新者
早期采⽤者
早期⼤眾
晚期⼤眾
技術采⽤⽣命周期是美國⾼科技營銷⼤師傑弗⾥·摩爾在⾃⼰的書《跨越鴻溝》⾥提出的概念。技術采⽤
⽣命周期是⼀個⽤來衡量⽤戶對某項新技術接受程度的模型，它認為⼀個新的技術，從⼀開始出現到最
后⾛向成熟，必然會經歷創新者、早期采⽤者、早期⼤眾、晚期⼤眾的階段。
雖然每個⼈群間都會有裂縫，但是早期采⽤者和早期⼤眾之間的那條裂縫最⼤，這條裂縫就是傳說中
的“鴻溝”，只有跨越過這條鴻溝，滲透到早期⼤眾這個⼈群，產品才等於是進⼊了主流市場。
希望您結合國內使⽤和發展情況，把以下技術對應到技術采⽤⽣命周期相應的不同階段中：
Java/JVM
Java版本（8～13）；
OpenJDK定制版或者公開發⾏版，Oracle JDK, OpenJDK by
Oracle/Redhat/Azul/Alibaba/Amazon, 或者其他；
⾮Hotspot JDK⽣產實踐，如GraalVM、IBM OpenJ9；
語法與特性，例如：Lambda /Stream、Vector API等（可以從是否有哪些特性帶來了突出甚
⾄不可替代的⽣產價值的⻆度，評判他們在技術采⽤⽣命周期中的位置）；
JVM語⾔，Kotlin、Scala、Groovy、其他；
不同層次的主流框架：Java EE（Jakarta EE）、Spring Framework、RxJava 、Vert.x、Netty；
微服務領域：Spring Boot/Cloud、Dubbo、TarsJava、ServiceComb、其他
⼩⻢哥（@mercyblitz）：創新者 早期采⽤者 早期⼤眾 晚期⼤眾
Java 13 Java 11 OpenJDK Java 8
Jakarta EE GraalVM Reactive
Streams
Lambda/Stream
Apache Dubbo (ECO
System)
Vert.x Kotlin Scala、Groovy
TarsJava RxJava/Reactor Java EE（Jakarta EE）、
Netty
ServiceComb Spring Framework
Spring Boot/Cloud
Apache Dubbo
InfoQ英⽂站結果供參考
第⼆部分：Java趨勢點評
對第⼀部分中您所歸類的處於不同階段的技術，請您逐⼀做出如下點評問題包括：
某個技術為什么要被划在這個技術采⽤⽣命周期內？這個技術在國內的發展情況以及機遇和挑戰是
什么？
⼩⻢哥（@mercyblitz）：
Java / JVM 語⾔ - Java 8 已被業界普遍接受，⽆論像 Spring Framework、Spring Boot，以及 Spring Cloud 這樣的現代 Java 框架，還是類似於 Vert.x、RxJava 或 Reactor 這類⼩眾框
架，均已構建在 Java 8 以及更⾼的版本之上。同時，Lambda 語法以及 Stream API 也在開
發⼈員的⽇常⼯作中⼴泛地運⽤，並且沒有看到語法回退的趨勢。因此，Java 8 和
Lambda/Stream 可歸類為“晚期⼤眾”。 JVM 語⾔ Scala 和 Groovy 已快成為明⽇⻩花，往昔
的光芒逐漸地被后期之秀 Kotlin 替代，故 Scala 和 Groovy 屬於“晚期⼤眾”，⽽ Kotlin 則納
⼊”早期⼤眾“ 之流。然⽽ Java 9 的被接受程度則沒有那么幸運，盡管我們等待它的到來已有
數年。 Java 模塊化作為 Java 9 核⼼的特性，就我個⼈⽽⾔，完全能夠理解和接受它的設
計。雖然模塊化增強了模塊的隔離性，減少了內存的 Footprint，然⽽，它更強的封裝性⽆
形之中增加了管理依賴的成本。所謂曲⾼和寡，誇張地說，模塊化形同虛設。因此，應⽤升
級 Java 9 的效果相當於 Java API 以及 JVM 的更新。同時，Oracle 宣布從 Java 9 開始，每半
年將更新⼀個 Java ⼤版本。那么，更多的⼈會選擇 Java 11 這樣的⻓期⽀持（Long-Term -
Support, LTS）版本，換⾔之，Java 9/10 則成了過渡版本（non‑LTS） 1 。因此，Java 11
將是未來 Java ⽤戶的最可能選項，將其列為“早期采⽤者”。⾄於 Java 13，最近有注意到該
本版在新 GC 算法的提升以及 Socket 實現上的變化 2 ，還是⾮常令⼈期待的，故排在“創新
者” 之列。除了模塊化之外，Java 9 還有⼤量的 API 更新，在偏開發側的部分，Flow API 可
能是最有吸引⼒的，提供了 Reactive Streams 3 標准接⼝以及實現，並且內建了 HTTP
Client Reactive 實現。盡管 Spring 和 Eclipse 社區⼤⼒的推⼴，並且 Java Lambda 以及
Stream API 也流⾏開來，不過對開發者⽽⾔，Reactive Streams 技術還是相對陌⽣，將其
放在 “早期⼤眾“。同理，Spring 引⼊的 Reactor 框架也屬於“早期⼤眾” 階段。雖然 RxJava
並⾮ Reactive Streams 的實現，但是相較於前兩者⽽⾔，它在 Reactive 編程中的地位必然
是有過之⽽⽆不及的，故也在 “早期⼤眾“ 之中。
OpenJDK - 由於 Oracle 宣布 2019 年伊始，Oracle JDK 8 以及更⾼版本在服務器端部署不再
免費，OpenJDK 則成為⼤多數 Java ⽤戶的選項。盡管 Oracle JDK 與 OpenJDK ⼏乎出⾄於
同⼀家之⼿，不過OpenJDK 很可能被認為是⼀種退⽽求其次的選擇。對於具備⾃主研發的企
業，它們可能選擇在 OpenJDK 的基礎上，⾃定義分⽀繼續開發。在⼀定程度上，Java 的發
展⽅向出現了裂痕，所以未來仍存在着不確定性，故將其放置於 “早期⼤眾“
⾮Hotspot JDK⽣產實踐 - 按照 GraalVM 官⽅的描述，GraalVM 將會是下⼀代的 JVM 基礎設
施，也是 Oracle 的重點項⽬，能夠將傳統的 JVM 進程 native 化，那么未來 Java 的性能提
升以及快速啟停則不再遙遠，不夠⽬前還尚不可知其兼容性情況以及明確的商業化條款，列
為“早期采⽤者 應該是合理的
不同層次的主流框架
Java EE - 在 Java ⽣態中，絕⼤多數應⽤直接或間接地使⽤了 Spring Framework，這
個曾經以輕量級著稱的框架，⽬前顯然“名不副實”，不過巨⼤的⽤戶基礎，早已進⼊“晚
期⼤眾”的⾏列。相反，Java EE 規范或者重組后的 Jakarta EE 4 則寂寥許多。實際
上，作為 J2EE 或 Java EE 的模仿者，盡管 Spring Framework 多半的特性和實現向
JSR 5 參考。⼀定程度上，Spring Framework 的流⾏“壓縮”了 Java EE 以及 JSR 的認
知空間，因此不少的開發⼈員不知道 Java EE API 或者 JSR 的存在，尤其是年輕的國內
從業⼈員。當然，Spring 也反哺了少量標准給 Java EE，⽐如 JSR 330 6 ，因此，將
Java EE 列為 “晚期⼤眾” 是毋容置疑的。值得⼀提的是，Jakarta EE 在 Eclipse 基⾦
會 7 的帶領下能否再次“偉⼤” 值得期待，后續未來 Jakarta EE 將是“創新者”成員
⽹絡框架 - Java 的⽹絡框架只有兩種，其⼀是 Netty，其⼆則是其他。如此描述也絲毫
不誇張，畢竟⼤多數與⽹絡相關的框架或中間件都和 Netty 多少存在關聯，如 Apache
Dubbo、Spring 5 Web Server、Jersey 等，所以“晚期⼤眾”的排⾏眾望所歸。
微服務框架 - Java 微服務框架的王者⾮ Spring Boot 和 Spring Cloud 莫屬，進過數年的⽣產使⽤，兩者早已屬於“晚期⼤眾” 的技術棧。相對應地，Apache Dubbo 出現和開
源的時間⽐ Spring Cloud 早不少，⽆論是性能還是穩定性，相對於后者要優秀不少，
因此，Apache Dubbo 也屬於 “晚期⼤眾” 框架。不過，最新的 Apache Dubbo ECO
System（⽣態系統）則基於 Apache Dubbo 衍進的 Cloud Native 解決⽅案，⽬前尚
未枝葉茂盛，處於 “創新者” 陣營。⽽⼩眾 的 Vert.x 則由於編程模型以及 API 熟悉度等
客觀條件所限，它不得不仍處於 ”早期采⽤者”。類似，TarsJava 以及 ServiceComb 最
近才出現，⽤戶的認可度和穩定性稍微成熟，同樣處於 ”早期采⽤者”。
國內是否在某個相對完整的領域，形成甚⾄開始引領技術趨勢？
⼩⻢哥（@mercyblitz）：在國內的開源軟件中，Apache Dubbo（后⽂簡稱 Dubbo）常年受到
業界的⻘睞，並榮獲多次殊榮。個⼈認為 Dubbo 有機會引領技術趨勢。Dubbo 從過去的⾼性能
RPC 框架，正在⾛向 Cloud Native 的⽣態系統（后⽂簡稱 Dubbo ECO System）。具體執⾏的
步驟也是 Dubbo 社區對 Cloud Native 的發展趨勢研判，⾸單其沖的是 Dubbo 在 Spring Cloud
場景下的整合。這部分⼯作已在 Spring Cloud Alibaba 項⽬中完成，作為項⽬中的核⼼成員，
Dubbo Spring Cloud 可⽆縫地替換過傳統 Spring Cloud OpenFeign，不僅提供更好的性能，並
且具備更多的負載均衡策略和熔斷等特性。同時，靈活的擴展點和內建實現幫助 Dubbo 適應不同
語⾔、環境和基礎設施。隨着 Dubbo 內核即將發布 Cloud Native（即將發布）特性 ，能夠將
Dubbo 幫助獨⽴於任意的基礎設施，實現 Dubbo（原⽣）與 Spring Cloud（原⽣）調⽤互通，
甚⾄在 K8S 場景下。⽆論 Dubbo 身處何處，統⼀的編程模型幫助開發⼈員快速和⾼效地實現業
務邏輯，達成 “Write Once, Run Anywhere” 的⽬的。后續，Dubbo 在多語⾔、Mesh 化 以及
Istio 的建樹將逐⼀呈現。
第三部分：應⽤實踐
請您盡可能詳細地回答以下問題，這些問題的回答除了作為趨勢報告的⼀部分之外，還可以作為您所在
企業的技術實踐，單獨成⽂（InfoQ記者將針對每位嘉賓所在企業和技術實踐，補充個性化問題）：
Java相關：
您的企業使⽤的JDK版本情況，是否采⽤了某個OpenJDK 發⾏版？您如何看待OpenJDK 在國內的
發展？（如果沒有采⽤，原因以及后續計划？）
⼩⻢哥（@mercyblitz）：在開源⽅⾯， OpenJDK 的選擇僅為 Oracle 官⽅提供。如果是公
司內部的話，則是 OpenJDK Alibaba 的分⽀。OpenJDK 在國內直接拿去使⽤的多，有能⼒
圍之擴展的公司鳳⽑菱⻆。可能隨着 OpenJDK 不同分⽀的成熟，未來國內公司選擇⾯將會
更⼴
您的企業⽬前在⽀持Java技術棧⽅⾯的策略是什么？計划和⽬標是什么？相關的核⼼痛點或者業務
需求是什么？
⼩⻢哥（@mercyblitz）：關於公司在戰略層⾯的設定，個⼈是不是⾮常清楚的。不過，作
為⼀名基礎設施的研發⼈員，⾃身遇到和周遭聽到同事抱怨的痛點還是存在的。⽐如，Java
9 之后的版本更新問題。 Reactive Streams 推⼴和落地時的阻礙，畢竟⼤多數開發⼈員從事
業務開發，業務系統的穩定性是他們核⼼ KPI 之⼀，他們缺少⾜夠的勇⽓和動⼒蒸騰新技術
的引進、也沒有時間和精⼒關注其中細節，尤其當沒有明顯特性變化的基礎設施 和 API 升級時。對於本⼈⽽⾔，我⽐較關⼼ JVM 中的變化，包括 GC 算法和性能提升，⽐如 C1 和 C2
編譯所導致的延遲和資源開銷，如何幫助 JVM 快速啟停，因為這些會限制 Java 作為編程語
⾔在雲原⽣時代的想象空間
對於當前Java的整體發展情況，您有什么感想？
⼩⻢哥（@mercyblitz）：Java ⽬前仍具在編程語⾔排⾏榜上奪魁，不過在整體⽐重上微幅
下滑。個⼈看來，未來這個趨勢還將持續。究其原因，⼀⽅⾯是由於新語種出現的中短期效
應，⼀⽅⾯是 Java 的編程復雜度並沒有明顯的降低，⽐如 I/O 處理、並發/並⾏計算，以及
類加載等等。再者是 Java 與操作系統之間的交互仍不夠充分，盡管 Java 9 開始提供了不少
的 API，然⽽了解和使⽤的群體不⾜。Java 在這⽅⾯明顯不及 GO 語⾔。
從語⾔層⾯來看，Java 正在向主流⾮ Java 語⾔融合，解決其中鴻溝的起⼿式就是語法的變
化，⽐如 Java 8 的 Lambda 表達式 和 Java 10 的局部變量類型（ var ）等。個⼈認為這是
⼀件好事，未來前后端不分家，相互滲透，對於彼此語⾔都是良性發展。
除此之外，個⼈⽐較期待的是 GraalVM 對 Java 的改變，傳統 Java 應⽤必須依賴 JVM 進程
加載字節碼后解釋執⾏，⽆法保證所有的代碼能夠在運⾏期編程完成，不免有運⾏時編譯所
帶來的性能開銷，從⽽影響 JVM 的啟停時間，簡單地說，這種⽅式不夠 Native，對於雲原⽣
或許不夠友好。如果未來 GraalVM 的社區版也能夠像 OpenJDK 那般“親⺠”，那么，Java 的
變化將是顛覆性的。
微服務相關：
請介紹您的企業是否進⾏了微服務實踐？如果是，在整體系統架構中的⽐例是多少？如果不是，是
否有相關計划？
您所采⽤的主要微服務框架是什么？如何判斷國內該領域的技術發展情況？您認為微服務主流框架
的爭奪是否塵埃落定？
您如何看待Service Mesh在國內的發展現狀和發展前景？
參與專家：
⼩⻢哥(@mercyblitz)，《Spring Boot 編程思想》作者、Apache Dubbo PMC 和 Spring-Cloud
Alibaba Architect
1. Oracle Java SE Support Roadmap - https://www.oracle.com/technetwork/java/java-se-support-roadmap.html↩
2. Java Performance Tuning News August 2019 - http://www.javaperformancetuning.com/news/news225.shtml↩
3. Reactive Streams JVM - https://github.com/reactive-streams/reactive-streams-jvm↩
4. Jakarta EE - https://jakarta.ee/↩
5. Java Community Process - https://jcp.org/en/home/index↩
6. JSR 330: Dependency Injection for Java - https://jcp.org/en/jsr/detail?id=330↩
7. Eclipse Foundation - https://www.eclipse.org/org/foundation/↩