趋势报告框架
第⼀部分：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/↩