可能是国内第一篇全面解读Java现状及趋势的文章

这张中国 Java 技术采用生命周期概览图是本次趋势报告的精华，结论来自于各位专家的判断。某些方面专家们观点出奇的一致，当然也有很多部分专家观点并不相同。可谓是金句频现、火花四溅。

技术采用生命周期划分方式

技术采用生命周期是美国高科技营销大师杰弗里·摩尔在自己的书《跨越鸿沟》里提出的概念。技术采用生命周期是一个用来衡量用户对某项新技术接受程度的模型，它认为一个新的技术，从一开始出现到最后走向成熟，必然会经历创新者、早期采用者、早期大众、晚期大众的阶段。

虽然每个人群间都会有裂缝，但是早期采用者和早期大众之间的那条裂缝最大，这条裂缝就是传说中的“鸿沟”，只有跨越过这条鸿沟，渗透到早期大众这个人群，产品才等于是进入了主流市场。

重要结论

1、Java 13 处于创新者阶段，Java 11 处于早期采用者阶段，Java 8 处于晚期大众阶段。

2、OpenJDK 处于创新者阶段。

3、非 Hotspot JDK 生产实践——Graal VM、IBM OpenJ9 处于早期采用者阶段。

4、Lambda /Stream 处于晚期大众阶段、Vector API 处于创新者阶段。

5、Kotlin 处于早期大众阶段，Scala 和 Groovy 处于晚期大众阶段。

6、微服务框架：Spring Boot 和 Spring Cloud 进入晚期大众阶段；ServiceComb 处于早期采用者阶段；Apache Dubbo 处于晚期大众阶段；Tars 处于早期大众阶段。

技术采用生命周期解读

在上一章节我们已经先把各位专家的观点和结论抛了出来，但是结论背后还需要很关键的原因解读，所以这一章节就按照 Java/JVM、不同层次的主流框架、微服务这三个部分，来逐一呈现。

Java/JVM

其实在 Java 版本方面，各位专家的观点完全一致：Java 13 处于创新者阶段，Java 11 处于早期采用者阶段，Java 8 处于晚期大众阶段。

在 InfoQ 面向开发者的 Java 使用版本调查中，毫无悬念，在参与问卷调研的开发者中，88.7% 正在使用 Java8 版本，这些人当中只有 35% 有升级计划，剩余 65% 并没有升级计划。

杨晓峰认为这一情况也正常：Java8 在可预见的将来依然会是生产的主体，放在晚期大众阶段是合理的。但是对于很多头部厂商来说，Java11 或者再后续版本，有可能陆续出现一定规模的生产化部署。他认为这样的趋势只会在头部公司发生，如果一个公司对大堆栈 GC 能力、延迟 SLA 等方面要求没有那么高，就没有足够动力去做相关升级，也未必有技术力量解决版本评估、兼容性修正等现实问题。所以结论就是：Java11 处于早期采用者阶段。

对此黄飞补充：也正是因为 Java11 处于早期采用者阶段，因此相关的资料较少，遇到问题会有比较高的学习成本，例如 JFR 对 11 的支持，JMC 对 Java11 的分析能力较弱。

而对于 Java 13，小马哥认为该本版在新 GC 算法的提升以及 Socket 实现上的变化还是非常令⼈期待的，因此 Java 13 排在创新者之列。

对于 Java 的升级，Oracle 宣布从 Java 9 开始每半年将更新一个 Java 大版本——Java 11 是长期支持（Long-Term -Support, LTS）版本，Java 9、10 则成了过渡版本（non‑LTS），因此，陈楚晖不建议用户在生产中使用 Java 9、10。在他看来，小版本升级相对风险是比较小的，而大版本变更则会有可能需要更改大量的代码，这也是为什么这么多人还在坚持用 Java8，而不去更新 Java 11、12、或者 13 的原因。

对于开发者升级 Java 动力不足的原因，李三红的解释更为详细，他认为有两个原因：

敏捷的基础底层架构对软件升级的支持，企业对底层架构的重视程度也是 Java 升级的一个很关键原因。中国的企业业务发展都很快，但是其实很多对底层架构的支持和重视是不足够的。底层架构是否在企业内部被统一强管控，是否很容易支持不同软件版本的灰度，并能通过有效的预发测试，覆盖软件升级不兼容等带来的不确定性，这都考验着软件升级的难度。

另外一点，如果企业享受不到技术升级带来的红利，包括性能、编程效率等多方面提升，势必也影响升级的积极性。

从此次 InfoQ 面向开发者的调研来看，对于目前 Java 的新特性和发展方向，56% 的开发者认为可以解决当前的主要业务挑战，24% 开发者的观点是不能。这也从另一层面表明：Java 经常被吐槽演进太慢，但是业界对新版本的采用并不十分积极，这可能反映了 Java/JVM 发展与开发者的实际需求存在某种脱节。

OpenJDK 定制版或者公开发行版

由于 Oracle 宣布 2019 年伊始，Oracle JDK 8 以及更⾼版本在服务器端部署不再免费，因此 OpenJDK 就成为了大多数 Java 用户的选项。根据《JVM 生态系统报告 2018》调查显示，70% 的开发者选择使用 Oracle JDK，21% 的开发者选择使用 OpenJDK。陈楚晖也介绍了国内的情况：目前国内开发者使用最多的依旧是 Oracle JDK，其次是 IBM JDK，也有部分企业采用 OpenJDK。报告链接：

https://snyk.io/blog/jvm-ecosystem-report-2018/

对于 OpenJDK 的技术采用生命周期划分，专家们有一些观点上的不一致，杨晓峰认为虽然国内很多头部厂商都在定制 OpenJDK，但是目前定制 OpenJDK 被采用范围还都有限，这也跟上文数据结果吻合，所以他会把 OpenJDK 归在创新者阶段。

但是对于参与 OpenJDK 的国内厂商来说，可能看法更加积极。在李三红看来：厂商是否转向 OpenJDK，还有一个重要考量因素就是看他们是否愿意付费使用 OracleJDK，如果不是的话，未来 OpenJDK 可能会逐渐取代 Oracle JDK，目前国内头部厂商都在 OpenJDK 上有所动作，所以他把 OpenJDK 定义在早期大众阶段。阿里巴巴使用并开源了 OpenJDK 长期支持版本 Dragonwell，目前阿里巴巴大部分的应用运行在 Dragonwell 8, 有些已经运行在 Dragonwell 11。

据来自美团的吴革介绍：美团现阶段正在测试基于 OpenJDK 的 MtJDK，作为美团 JDK 基础服务。此外，美团主要会关注 Redhat 和 Amazon 的升级。由于 Azul 没有公开 OpenJDK 源代码，所以美团没有基于 Azul 进行研发。

来自小米的黄飞也介绍了小米对于 OpenJDK 的应用情况：小米主要使用 OpenJDK8 以及 11 版本，目前对 OpenJDK 主要还是以使用为主。

从现有的 OpenJDK 阵营来看，目前分为两类，一类是 IT 和云厂商，他们对外提供发布、销售的 OpenJDK 版本——Amazon、Redhat、Azul 、阿里巴巴、腾讯都在自己生产（除了微软分发 Azul）；另外就是技术上的强需求导致自身有定制 OpenJDK 的公司，他们的 OpenJDK 产品较难突破内部使用的范围，比如我们采访调研的美团、小米。

对于这样的一个阵营划分，杨晓峰有一个观点：从 OpenJDK 发布版的竞争格局来看，最终会演变为云的格局，坚持下来的会是头部云厂商或与其合作的软件厂商。换句话说大家在公有云、私有云等方面的竞争格局，深刻影响着在 OpenJDK 上的竞争格局。毕竟对于企业来说，做 OpenJDK 也需要有利可图，没有广泛的用户群体和对等的收益，很难支撑基础软件的长期演进。

我们把以上观点抛给了此次调研采访对象——IT 公司和云厂商阵营的代表李三红，在他看来：在 Java 收费的情况下，OpenJDK 一定是大势所趋，Java 会越来越开放，深度参与 OpenJDK 也是为了通过社区驱动 Java 往前走；另外，在当前企业上云的大趋势下，如果客户的现有系统是用 Java 写的，云厂商在为客户提供服务的时候势必要考虑如何让 Java 生态变得更好，这也是符合客户的诉求。

不过杨晓峰也表示：从企业 IT 决策角度来说，相当一部分企业更加看重的是长期可信的支持、及时的安全漏洞和 bug 修复等。也会有可观的企业会决定风险自负，直接获取免费、自由的 OpenJDK 发行版，并不会购买支持服务，甚至不考虑升级 JDK，直到今天 JDK 7 等历史版本仍有可观的占有率，正是说明了这一点。

非 Hotspot JDK 生产实践——Graal VM、IBM OpenJ9

Graal VM 被列为早期采用者阶段，对此李三红表示：Graal VM 已经在 Oracle Cloud 生产环境大规模使用，TCK 兼容。值得一提的是，Graal VM 下的静态编译 SVM 造成了 Java 语言一些方面的不兼容， 这个也是整个社区担心的地方。如何让 SVM/ 静态编译能纳入到 Java Language/JVM Specification 里来？值得关注。

杨晓峰的看法更加极端：在国内，怀疑 Graal VM、IBM OpenJ9 进入普遍生产实践的可能性会比较低。怀疑它们可能不会再走到下个阶段，很难跨越技术鸿沟。提及原因，他认为主要是国内公司大都在强调业务创新的速度，没有做如此深度的底层更新的耐心和业务必要性。而且从技术上来看，在动态特性支持等需求没有平滑解决方案之前，迁移难度很高，会带来很高的开发和运维成本。所以对于国内普通企业用户来说，没有单独关注的价值。未来更加现实的技术采用路径是，用户使用集成了 Graal VM 先进技术的 OpenJDK 主分支。同样，IBM OpenJ9 有很多独到的技术，如果能够合并入 OpenJDK 主分支，更能创造普遍的生产价值，否则难免会被局限在 IBM 中间件等用户群内部。另外，订阅 Graal VM 服务的具体信息可能在今年 Code One 会有说明，大家有兴趣可以关注。

Lambda /Stream、Vector API 等语法与特性

对于 Lambda /Stream 等语法与特性，采访调研专家认为应该归类在晚期大众阶段。小马哥认为这些语法与特性在开发人员的⽇常⼯作中⼴泛地运用，并且没有看到语法回退的趋势。吴革表示：在美团内部，目前已经大量使用 Lambda 和 Stream 表达式。

而对于 Vector API 等前沿版本特性，杨晓峰认为还只在个别头部公司处于原型阶段，应该被归在创新者阶段。

Kotlin、Scala

对于 Kotlin 和 Scala，我们也采访调研了两位 Kotlin 和 Scala 领域的专家。

在今年 5 月份的 Google I/O 大会上，Google 官方正式宣布：Kotlin 是 Android 应用程序开发人员的首选语言。这是否意味着 Java 占据 Android 开发绝对统治的时代一去不复返了？

虽然身为 Kotlin 专家，但是张涛的观点还是很理性而客观的，他表示：每几年都会有语言号称要取代 Java，但是从诞生到现在，好像依然没有语言能取代它。这主要源于 Java 在服务端的稳固地位，没有语言能够做到 Java 这样完善的社区、用户群和三方库支持。

张涛认为 ：Kotlin 在国内应该处于早期大众向晚期大众过渡阶段，在未来一两年内，会有大部分的 JVM 平台开发者开始使用 Kotlin。

在 2017 年年底，张涛曾经做过一次调查，邀请将近 1000 名 Android 开发者，了解他们的项目中是否使用了 Kotlin。当时的结果是 30% 的人使用过 Kotlin，60% 的人听说过 Kotlin， 还有 80 多人没有听说过。他相信目前国内的 Android 应用应该 90% 都包含有 Kotlin 代码。

此前 InfoQ 曾对字节跳动大数据工程师、Scala 程序员王石冲以及另外几位来自 Scala 社区的专家进行过一次访谈，了解 Scala 在国内的发展情况。对于有人认为的 Scala 难成主流的说法，王石冲表示：Scala 为什么非要成为主流呢？它在自己适合的领域做王者就够了，主流不主流其实并不是那么重要。

王石冲把 Scala 归在早期大众或者晚期大众阶段：Scala 在可预见的未来都会是小众——有一少部分人非常喜爱它；有一少部分团队或公司在使用它；大部分人最多只是听说过它而已。Scala 无论是在国内还是在国外，都称不上是主流语言。不过有部分团队水平很高的公司，还是深度应用 Scala 来做事情。成名的例子就有 Twitter、LinkedIn、Verizon 等。金融行业则有摩根士丹利、渣打等（但是他们作为闷声发大财的典型，很少对外宣传自己的技术选型）。而很多硅谷的初创团队早期为了快速开发，也是采用的 Scala。在国内，除了小米、阿里和腾讯的部分团队以及类似于 GrowingIO、水滴这样的初创公司和一些广告公司外，大部分开发者都是应用 Scala 来做 Spark 开发。因为没有典型的、具有号召力的大公司主导，所以 Scala 在社区方面做得也一般。

Spring Boot/Cloud、Apache Dubbo、TARS、ServiceComb 等微服务框架

对于微服务框架的技术采用生命周期的划分，我们分别采访调研了阿里、腾讯、华为等几家大厂的专家，这几家大厂都拥有各自的微服务框架解决方案。不过微服务框架的王者依旧非 Spring Boot 和 Spring Cloud 莫属，对于这一点大家也达成了共识——Spring Boot/Cloud 处于晚期采用者阶段，拥有大量用户。从 InfoQ 此次面向开发者的调研来看，选择 Spring Boot/Cloud 的开发者占到 70%；其次是 Apache Dubbo，占到 20%；其他微服务框架的占比都还不太高。

田晓亮表示：Spring Cloud 社区依然在蓬勃发展，也开始为云厂商创造商业机会，如何与 Spring Cloud 结合，成为了云厂商要解决的关键问题之一。

华为大量的云服务和内部项目采用了 ServiceComb 的微服务解决方案。在田晓亮看来，ServiceComb 属于早期采用者阶段，虽然越来越多的企业选择了 ServiceComb 进行微服务转型，并获得了成功，但并未普及到早期大众阶段。ServiceComb 中微服务框架与 Service Mesh 可以融合使用，让用户有了灵活的选择。Java 依然是最流行的语言，但企业也终于能够选择其他语言进行微服务开发了。同时提供 Spring Cloud 的组件可以使其接入到 ServiceComb 中，帮助 Spring Cloud 用户平滑向多语言转型，Java 不再是微服务唯一的选择。

Apache Dubbo 一开始并不叫这个名字，Dubbo 一开始只是阿里内部的一个系统，2010 年 Dubbo 项目进行重构，2018 年初，Dubbo 项目正式进入 Apache 孵化器。在小马哥看来，Apache Dubbo 属于晚期大众阶段，不过最新的 Apache Dubbo ECO System（生态系统）则是一个基于 Apache Dubbo 衍进的 Cloud Native 解决方案，目前尚未枝叶茂盛，处于创新者阵营。

对于 Apache Dubbo，黄飞表示：它在 RPC 中间件这个领域可以算得上引领者之一。Apache Dubbo 的服务注册与发现、服务治理相对完善，支持灰度发布，智能的负载均衡策略、可视化的服务治理与运维工具便于开发人员上手。可以说 Dubbo/Dubbox 在 RPC 框架 / 微服务领域已经展露头脚甚至在某些方面已经形成优势。

TARS 在腾讯内部叫 TAF(Tencent Application Framework)，是腾讯应用产品最多、最广泛的微服务开发框架，并且已经在腾讯大规模应用了超过十年。2017 年中旬，腾讯正式将 TARS 开源，开源后一年便成为 Linux 基金会开源项目。由于相对其他微服务项目开源晚，错过了很多社区发展红利。

对于 TARS，据单致豪介绍，不同的微服务主流框架可以满足不同的应用痛点，TARS 则原生专注多语言和高性能。他认为 TARS 已经有大型互联网公司广泛使用，已经从早期采用者阶段迈过了鸿沟，进入了早期大众阶段。

Java 应用实践

阿里巴巴李三红：目前阿里巴巴大部分的应用运行在 Dragonwell 8，有些已经运行在了 Dragonwell 11， 我们正在逐步推动从 Java8 到 Java11 的升级，充分享受技术红利。

美团吴革：美团现阶段主要使用 Java8，很少一部分是 Java7。部分核心团队正在尝试 Java 11。在美团内部采用的开发版本 JDK 主要还是 Oracle JDK。我们在服务器上的 JDK 版本主要是美团自己的 MtJDK 和 Oracle JDK。美团现阶段正在测试基于 OpenJDK 的 MtJDK，作为美团 JDK 基础服务。

MtJDK 主要基于 OpenJDK 构建，现阶段主要针对补丁和安全性进行维护。现阶段在特定业务线内部进行测试和应用。未来配合 Serverless 等基础服务升级，MtJDK 会在 JDK 启动性能和增强应用之间的隔离进行深度定制。

小米黄飞：小米主要使用 OpenJDK8 以及 11 版本。目前对 OpenJDK 主要还是以使用为主，主要的业务关注点在于这个版本是否为长期支持；是否有更加高效易用的特征，例如 GC 算法由 CMS、G1 升级到 ZGC 等；开源社区是否活跃；以及对遇到的问题是否有足够丰富的资料与讨论等。

Java 作为使用最为广泛的语言，最近几年还是有比较大进步的，无论从语法的易用性上还是性能上都有很大程度的提升。吸收了函数式编程的思想，lambda 表达式、Parallem stream、Var 变量等提升了开发人员的效率与代码的简洁性。ZGC 无疑是一项重大的改进，在一定程度上解决了 Java 天生的 GC 问题。

腾讯单致豪：腾讯内部占领导地位的开发者是 C++，同时有大量的 Node.Js、Golang、Java、PHP、Python 开发者，当然也有少量的 Rust、C# 的开发者。我们在海量用户的后端大部分采用 C++ 和 Golang，Java 在前端和大数据方面有广泛使用，在对外 ToB 的交付中也大量采用。由于腾讯的开发者使用了多种开发语言，而且不同开发语言在不同领域有不同优势，所以当前要解决的问题是多语言开发的服务互通问题，一套支持多语言的微服务开发框架是必需品，TARS 也是在这样的多语言背景下诞生。

美团吴革：美团的 Java 技术栈策略偏向稳定，在稳定的基础之上推动技术升级。Java 核心痛点就是依赖升级，当一个 jar 包升级，必须一个服务一个服务升级，不能自动化整体升级，所以对于美团来说，正在解决相关依赖升级的问题。

红帽陈楚晖：红帽主要采用市场流行的 Java 技术栈。大部分的项目都会采用 Java 进行开发，主要是因为 Java 比较成熟，有很多成熟的技术框架可以直接使用，同时也有很多类似的代码可以重用，也比较容易找到熟悉 Java 的技术人员。这样开发的速度和效率会比较高，以及成本会比较低。

阿里巴巴小马哥：大多数应用已实施微服务架构，微服务应用的比重达 80% 以上。

腾讯单致豪：早在 2008 年以前，腾讯已经开始实践“大系统小做”的海量服务之道理念，大量的服务已经是遵循微服务理念开发。因为腾讯要支持快速迭代和敏捷研发，所以微服务比例占比在 95% 以上。核心业务模块因为要支持海量用户的巨大流量，100% 都是微服务。腾讯内部使用 TARS 开发的微服务已经超数十万个节点，在规模上来看，是全球最大的微服务集群之一。

美团吴革：美团在 2015 年开始微服务架构演进，核心系统已经 100% 微服务化。

红帽陈楚晖：已经进行了微服务实践，在整体系统架构中占比不超过 30%。

华为田晓亮：华为云的所有服务都采用微服务架构，但并非所有服务都用了某种微服务解决方案——比如 ServiceComb，Istio 或者 Spring cloud，各服务主要是自行实践微服务设计模式。但几乎所有应用服务都采用了华为云容器服务 CCE(Cloud Container Engine) 的 kubernetes 集群。

阿里巴巴小马哥：2015 年初开始，阿里巴巴集团的应用架构逐渐由 SOA 衍生至微服务，所使用的微服务框架主要以 Spring Boot / Spring Cloud 和 Apache Dubbo（HSF）为主，涵盖所有 Java 中间件核心基础设施、九成以上的内部系统，以及阿里云商户应用等。同时，基于 Spring Cloud API，阿里巴巴衍生并开源出一套全新的微服务框架 - Spring Cloud Alibaba，并且正走向下一代 “云原生” 架构，越来越多的应用开始尝试 Serverless 以及 Service Mesh 等前沿技术。相信未来微服务在不同语言和平台上将会提供更多的选择，至于那时谁是王者或主流框架，这个问题的答案已经不再重要。

腾讯单致豪：不同的微服务主流框架可以满足不用的应用痛点，比如 SpringCloud、Dubbo 专注 Java 领域，TARS 则专注于多语言和高性能，充分发挥 C++ 的高性能、Go 的性能与高效兼顾、Java 的全能、Python 丰富基础库尤其是 AI 方面、Node.Js 和 PHP 便捷全面为 Web 而生等等优势。目前中国和美国大厂开源的微服务框架（腾讯的 TARS、阿里的 Dubbo、百度的 brpc、谷歌的 gRPC、Facebook 的 Thrift、Pivotal 的 SpringCloud）基本能覆盖所有用户的痛点，企业直接从开源社区选型能解决自己痛点的开发框架即可。

美团吴革：主要采用自研 OCTO 和 Pigeon，现在正在开发 Service Mesh 服务。现在国内主要是基于 Dubbo、Spring Cloud、Google gRPC 作为基础进行二次封装，主流框架选型已经相对成熟。

红帽陈楚晖：主要采用 Spring Cloud 的微服务框架，也对 Service Mesh（Istio）有研究。由于现有的微服务框架需要开发人员过多的介入，需要有大量的开发，所以目前大家比较看好 Istio。但是由于 Istio 还不够成熟，因此大家都还处于预研阶段。

华为田晓亮：华为许多的云服务和内部项目采用了 ServiceComb 的微服务解决方案，比如消费者云，在全世界运行着数千微服务实例来为手机用户提供服务。此外，华为云的音视频服务也运行着数千的微服务实例，来提供视频通话、音视频解码等服务。并且我们也向社区（通过 ServiceComb）和商业用户（通过 ServiceStage）提供解决方案。

阿里巴巴小马哥：个⼈对 Service Mesh 的看法是乐观偏谨慎的，一⽅⾯，作为从业人员，对于技术总有猎奇的心态。另外一⽅⾯，这个技术在设计上存在一些理想主义，比如，性能损耗以及稳定性，并且分布式场景中的典型问题并没有得到解决和改善，比如数据一致性、分布式事务等。据我所知，国内不少的互联⽹公司，如阿⾥巴巴、蚂蚁⾦服以及美团等已经开始在生产环境试点 Service Mesh，听起来这是一件好事。前沿的技术总需要有⼈去探险，如果成功，前人栽树，后人乘凉。至于它能否成功，主要看市场是否愿意买单。

美团吴革：未来 Service Mesh 会在跨语言场景下大放异彩。Service Mesh 主要是基于云平台和多技术栈场景下的痛点进行的开发，短时间内不会有爆发性的增长。但是基于原生云架构系统的增多，未来 Service Mesh 会不断演进，最终变为云原生架构下的网络基础服务。

腾讯单致豪：Service Mesh 目前还处在早期发展阶段，其理念设计已经决定了性能及维护性上会是它最突出的短板。但有部分企业包括腾讯已经尝鲜，也有小量周边不重要非核心业务在上面跑。Service Mesh 有着优美的架构理念，但性能确实让人担忧，社区生态也至少需要三年以上的发展时间。

华为田晓亮：大环境来看，传统企业面临的挑战依然是业务系统如何向微服务转型，以构建自己的业务平台，在这其中微服务框架是一种手段。为了寻求更快速地微服务化，开发人员就会避免学习陡峭的开发框架，而转向使用 Service Mesh。开发者将结合轻量的 SDK（例如对接监控系统、配置管理、AI 平台，而不是微服务框架）与 Service Mesh 来实现自己的业务系统，从繁重的架构工作中解放出来。这个发展历程在我看来大概需要 2-3 年的时间。而且，在我看来，最终站上舞台的并不是 Service Mesh，而是底层由 Service Mesh 提供支持的 Serverless 平台，用户感知不到 Service Mesh 技术的复杂性，否则将面临比开发框架更繁重的基础设施运维挑战。所以 Service Mesh 其实和 Serverless 的发展是绑定在一起的。Serverless 的普及和使用必然会帮助 Service Mesh 进行发展。

杨晓峰：在可预见的将来，Java 依旧是企业软件、大数据、电商等等最核心的技术栈。但是目前 Java/JVM 能力在云时代有一定局限性，比如云里强调的无服务器、微服务等场景，Java/JVM 都有一定短板。

另外 Java 新版本采用速度这么慢，本身就说明，Java 创新和实际需求存在某种程度的脱节——一方面大量创新会带来兼容性和版本混乱的问题；另外创新带来的优点却需要极大增大开发运维成本，这也让部分创新的价值被抵消了。

但是 Java 会被取代吗？应该也不会，目前在社区、工具、类库等等方面，Java 还没有真正意义的对手，但是最大的威胁是新的需求浪潮是否与你有关。我们可以看下 GitHub 上 Java 新项目的趋势，一定程度上可以佐证 Java 坚实的基本面和不可忽视的隐忧。

阿里巴巴李三红：从技术角度来看，Java（JDK）这二十几年的发展一直试图在 Productivity 以及 Performance 之间做最好的平衡。Java 是静态类型语言，但是为了生产效率提供了大量动态的特性比如 Bytecode Instrument、Dynamic Class Loading、Metaprogramming(Annotation、Reflection 等 ，这些形成了 Java 在运维、生产监控等领域的基石技术。同时由于 Java 大量的动态特性存在，使得它在面向云原生、Serverless 计算时 Memory Footprint、Startup 方面被人所诟病。这也是整个 Java 社区，当然包括 Alibaba Dragonwell 所试图解决的问题。

阿里巴巴小马哥：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 的变化将是颠覆性的。

美团吴革：当前 Java 已经发展成为一个庞然大物，语言上基本不会有太多突破，更多是借鉴和兼容。随着 GC 算法的升级和编译器换代，面对 Go 等新一代语言挑战，还有一战之力。

腾讯单致豪：毋庸置疑，Java 语言依然活力十足，但在某些方面已经失去优势，如云原生领域现在出现了更具活力的 Go 语言。纷繁的世界必定会出现多语言并存、不断替代的现象。回顾历史发展进程，一种语言要从出现到早期大众使用基本都需要十年时间，能历经十年磨砺生存下来的开发语言，必定是有很强的生命力，而且都会有不同的企业构筑其生态。正如上文所说：不同语言也会在自己优势之处持续发展，形成很强的竞争壁垒。

字节跳动王石冲：Scala 语言目前有两个大的目标运行平台——JVM 和 js，所以 Scala 作为一个语言和生态并不敢完全投资在单一目标平台上。虽然 JVM 本身在不断进步，但是 Java 已经被同平台的多种语言赶超，比如 Kotlin、Clojure、Groovy。

报告参与者介绍

杨晓峰，Java 技术专家，OpenJDK Committer。

李三红，阿里云智能资深技术专家，2014 年加入蚂蚁金服，现为阿里 / 蚂蚁 Java 技术负责人，有超过 10 年的 Java 开发经验。活跃于 Java 技术社区，在 Java 虚拟机领域拥有多项技术专利。

小⻢哥（@mercyblitz），《Spring Boot 编程思想》作者、Apache Dubbo PMC 和 Spring-Cloud-Alibaba Architect。

田晓亮，华为云 ServiceStage 首席工程师和 Apache ServiceComb PMC，7 年云计算领域工作经验，在 PaaS，混合云，DevOps，微服务，APM 方面有多年的实践经验。

单致豪，腾讯技术委员会和腾讯开源办公室成员，负责微服务框架 TARS 的开源生态，并将项目捐赠 Linux 基金会。云原生产业联盟专家顾问，DevOps 标准专家，GOPS 大会主席团。

吴革，美团点评高级技术专家，现在主要负责美团点评小象事业部系统架构工作。

陈楚晖，红帽 AppDev 首席架构师，开源技术专家，熟悉多种开源中间件，长期就职于国际知名软件公司，二十年中间件工作经验，拥有丰富的电信运营商、政府企业、金融等行业的系统集成、IT 项目管理经验，具有丰富的一线实践经验。

王石冲，字节跳动大数据工程师，Scala 程序员。译著有《反应式设计模式》。主要专注于基于 Scala 构建的反应式架构以及相关应用的实现。之前在从事中小型企业的实时数据流分析系统的开发。第四届阿里中间件性能大赛优胜奖，第一届阿里云 PolarDB 性能大赛季军。

张涛，网名 kymjs，Android 技术专家，“开源实验室”博主，Kotlin 技术推广者，四年前开始接触和使用 Kotlin 语言。带过团队，做过架构，写过应用，做过开源社区。曾先后在沪江、饿了么、携程工作，目前在一条生活馆负责移动开发管理工作。

黄飞，小米互联网商业部技术主管，在互联网商业化变现方面有丰富经验，负责小米互联网广告业务引擎与算法架构工程研发，在高并发分布式推荐系统有多年的实践经验。

特别感谢：感谢杨晓峰老师参与此次报告的前期策划，并在报告撰写过程中给予专业的建议和指导。