1991 年，James Gosling 带领团队开始了一个叫"Oak"的项目，这个就是 Java 的前身。1995 年，Java1.0 发布。“Write once, run anywhere"这句 Java 口号想必大家耳熟能详。Java 刚开始出现的时候主要面向 Interactive Television 领域，直至后来几年的发展，当时的 SUN（后来在 2010 年被 Oracle 收购）一度想用 Java 来打造桌面的网络操作系统，取代当时如日中天的 Windows。不过 Java 后来的发展，不曾想虽未在桌面领域内取得多大的建树，出乎意料地，却在企业级应用领域开花结果，占据了如今几乎统治的地位。失之東隅，却收之桑榆。

Sun 在 2006 年的 Java One 大会上，宣布 Java 技术开源，随后 2006 年底在 GPL 协议下发布 HotSpot 以及 javac，这是 Java 发展中的里程碑事件。阿里巴巴最早在 2012 签署 OCA，并参与到了 OpenJDK 的开发。

OpenJDK 是 JavaSE 开源的 Reference Implementation。在 JavaOne 2017 的 Keynote 上 (2018 年 JavaOne 被 Oracle 重命名为 CodeOne)，Oracle 承诺将开源所有的 OracleJDK 里包含的商业实现功能[1]。

在 2018 年发布的 Java11， Oracle 已经让 OpenJDK 和 Oracle JDK 两者的二进制文件在功能上尽可能相互接近，尽管 OpenJDK 与 OracleJDK 两者在一些选项之间仍然存在一些差异[2]。

另外，除了 OpenJDK 这条主线，在最近的几年里，Java 基础技术的开源有愈演愈烈趋势：2017 年，IBM 将内部使用 20 多年之久的 J9 虚拟机开源，并贡献到 Eclipse Foundation， 而随后 2018 年，Oracle 开源 GraalVM 1.0，其核心包含用 Java 写的Just-in-Time compiler/Graal, SubstrateVM 以及支持多语言解释器的 Truffle 框架。各个企业开源的主要动机，想通过开源构建并受益于一个更为强大的语言生态系统。

云 + 开源结合在一起，使得普通开发者以较低的门槛获得一流工具(链)的使用和体验，任何一家企业都可以像任何大型组织一样，使用的相同技术(democratizing)，这是开发者的黄金时代。

Java 仍然免费，但随着 OracleJDK License 变化开始转向收费，OpenJDK 会逐渐取代 OracleJDK 成为市场主流，这点也可以从 JVM 2020 生态报告中看出趋势：OracleJDK 从前一年的 70% 的开发者选择使用率降到 2020 年的 34%。

OracleJDK 收费，在客观上也加剧了 OpenJDK 生态的碎片化趋势，出现了包括 Alibaba Dragonwell 在内的多个基于 OpenJDK 的可选实现。

企业在选择使用那个 Java Vendor 的 JDK 版本时，几个方面的考虑因素可以参考：

这里分享下 Alibaba Dragonwell 在这些方面的计划与思考。

Alibaba Dragonwell 是阿里巴巴内部广泛使用的 AJDK (AlibabaJDK) 的开源版本，Alibaba Dragonwell 作为基石，支撑了阿里经济体内几乎所有的 Java 业务，经过了双 11 等大促的考验。Alibaba Dragonwell 主要针对的场景是数据中心大规模 Java 应用部署情况下，Java 应用稳定性、效率以及性能的优化与提高。

2019 年 3 月阿里开源 Alibaba Dragonwll 8.0.0，我们也一直正在践行开源时候的承诺，AJDK 内部使用的特性在逐步开源。到刚刚发布 Alibaba Dragonwell 8.3.3，我们已经开源了 JWarmup，ElasticHeap，多租户，JFR 等众多功能，协程 Wisp 2.0，GCIH 等也在开源的规划上。

同时，Alibaba Dragonwell 作为 OpenJDK 的下游，每个发行版都会同步上游最新更新，包括安全更新，问题修复等，并经过阿里内部大规模的应用集群测试。

在新技术 Adoption 方面，Alibaba Dragonwell 目前发布和维护了 Java 8,11 两个 LTS 版本，阿里 JVM 团队会根据实际业务状况，移植 Java11+ 的相关功能到 Java 8 和 11 两个版本，这样 Alibaba Dragonwell 用户可以在不跟进 Java 12,13 等这些 FR 版本的情况下，提前享受这些功能带来的技术红利。

纵观 Java 技术 20 多年的发展，始终围绕着两大主题：Productivity 以及 Performance。在很多情况下，Java 在设计上 Productivity 是优于 Performance 考虑的。Java 引入的 Garbage Collector 把程序员从复杂的内存管理中解脱出来，但在另一方面 Java 应用始终困扰于 GC 暂停时间的影响。Java 基于栈式虚拟机的中间字节码设计，很好地抽象了不同平台 (Intel, ARM 等) 的差异性，同时通过 Just-in-Time (JIT) 编译技术，解决的 Java 应用 peak 性能, 但在另一方面 JIT 不可避免引入了 Warmup 的代价，正常情况下 Java 程序永远需要先 load class，解释执行，然后再到高度优化的代码执行。

如果从 JVM 视角来总结梳理下目前 OpenJDK 社区正在发生，孵化的相关技术，主要从工具，GC，编译器，以及 Runtime 四个方面进行一个主要概括：

Oracle 从 Java 11 开源了其之前一直作为商业功能的 JFR，JFR 是功能强大的 Java 应用问题诊断与性能剖析工具。阿里巴巴也是作为主要的贡献者，与社区包括 RedHat 等，一起将 JFR 移植到了 OpenJDK 8， 预计 2020 年 7 月即将发布的 OpenJDK 8u262 (Java8) 将会默认带有 JFR 功能，这样 Java 8 的用户可以基于这个版本免费使用 JFR 功能。

无论是 Oracle 在 Java 11 发布的 ZGC，还是 RedHat 已经做了好几年的 Shandoath，都实现了 concurrent copy GC，解决 Large Heap 情况下的 GC 停机性能。ZGC 最新状态，在 9 月份即将发布的 JDK 15，ZGC 将从 Experimental 功能变为生产可用 [3] 。实际上，在 AJDK 11 上，阿里巴巴团队 JVM 团队已经做了大量 Java 11+ 到 Java 11 的 ZGC 移植工作，以及相关问题修复，2019 年双 11 和阿里数据库团队一起，让数据库应用运行在 ZGC 上，100+ GB Heap 情况下 GC 暂停时间可以保持在