Java 小想法: JDK 许可证

是的，Java已经25周岁了。 25周年，我们可以聊聊Java世界的一些见闻和小想法。首先我想到的，就是JDK许可证的变化，以及随之而来的困惑、误解，以及变化带来的生态效应。



这两年，影响Java生态格局最大的事情，莫过于起始于2018年的JDK许可模式和发布模式的变更。

老的许可证什么样？

十多年来，Java SE的授权一直使用BCL模式。BCL模式允许用户在一定的限制条件下，免费使用JDK。比如，下面就是一个免费许可及其限制的条款：

2. LICENSE TO USE. Subject to the terms and conditions of this Agreement including, but not limited to, the Java Technology Restrictions of the Supplemental License Terms, Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs. THE LICENSE SET FORTH IN THIS SECTION 2 DOES NOT EXTEND TO THE COMMERCIAL FEATURES. YOUR RIGHTS AND OBLIGATIONS RELATED TO THE COMMERCIAL FEATURES ARE AS SET FORTH IN THE SUPPLEMENTAL TERMS ALONG WITH ADDITIONAL LICENSES FOR DEVELOPERS AND PUBLISHERS.



由于大部分实际用户都能够满足这些限制条件，JDK一直被认为是一个免费的软件。事实上，BCL是一个兼具免费和付费的许可证。长期以来，付费的用户为Java SE的发展提供了必要的资金支持。

新的许可证什么样？

从JDK 11发布开始，也就是2018年9月份，Oracle开始发布两个不同许可证的JDK：开放版（GPLv2+CPE）和商业版。



开放版的JDK叫做OpenJDK，可以从jdk.java.net网站下载。商业版的JDK叫做OracleJDK，可以从Oracle.com网站订阅、下载和使用，也可以通过你的Oracle产品支持渠道获得。



BCL这种混合了免费和商用的许可证，除了容易引起混淆之外，还会给用户造成不必要的麻烦。比如有的用户只允许使用商业许可证，有的用户只允许使用开放许可证。免费和商用混合的许可证，给用户的许可证管理带来了一定的麻烦。发布两个不同的许可证，就没有这些麻烦事了。



而且，GPLv2许可证是比BCL的免费部分更加开放的许可；商业许可证是比BCL的商业部分更加明确、商业支持更到位的许可。



免费用户和付费用户本来就是两类不同的用户。现在，免费的用户可以获得更开放的许可，付费的用户可以获得更商业的支持。这是许可模式的简化。

OracleJDK有什么不一样？

和OpenJDK相比，OracleJDK有什么不同呢？



由于历史的原因，当Java SE开源的时候，有一些代码当时存在许可证的问题，没有办法开放源代码。比如ZGC和JFR。这几年，Oracle已经陆续地解决了这些许可证的问题，并且开放了这部分源代码。从JDK 11开始，OpenJDK和OracleJDK本质上没有什么区别。



既然是一样的，为什么还要使用两个许可证呢？都GPLv2不就简单了吗？有这个问题的用户，一定不理解商业许可的需求，和付费用户的诉求。

争议从何而来？

看似两个许可证模式对应不用的用户群体，各有所好，各取所需，为什么JDK许可模式的变更引起了这么多争议？过了一年多，再看看这个变更，为什么引起了Java生态格局这么大的变化？



除了许可证变更之外，我们还有关注随之而来的另外一个变更。这就是Oracle发布模式的变更。许可证本身没有什么问题，只是简化了用户的选择。但是发布模式的变更，给Java生态格局带来了巨大的变化。



记得十多年前，有一位Java One参会者提问，JDK发布太快了，他们跟不上，版本更新能不能再慢点？这个问题固然代表了一种观点。我对这个问题印象深刻，主要是因为我追出去老远解释大半天，这位拂袖愤懑的Java用户依然难掩对版本更迭过快的不满。



JDK发布有多快呢？Java SE 9之前，一般是两年或者三年一个版本。从Java SE 9开始，Oracle调整了版本发布策略，半年发布一个小版本，三年发布一个大版本（Long-Term-Support (LTS) release）。十多年前的哪位用户，一定惊掉了下巴。但是，紧跟市场、快速发布，是更适合现在创新和市场发展节奏的策略。



对于Java SE的设计和研发，这种发布节奏简直就是翻天覆地的变化。研发计划、资源配置、研发流程等都要跟着这种节奏调整。



Java SE 9之前，Java SE研发团队还有少许的时间照看JDK的更新版。半年一个版本的节奏，使得研发团队的不得不把主要精力放在关键问题的修复，和未来特性的扩展上。也就是说，Java SE研发团队的主要任务要朝前看。



那么，更新版怎么办？一个大版本要维护至少6年，没有更新版是一件不可想象的事情。幸运的是，到2018年，Java SE开放源代码已经十一二年了。Java社区已经积累了足够的力量。



2018年，这股力量有意愿，也有能力承接JDK的更新版了。



JDK是开源的，Oracle的每一个更新，都会体现在OpenJDK里。JDK社区只要评估这些更新，并且整合到以前的版本里，就可以获得相应的更新版了。



Oracle放手后，Redhat领导了OpenJDK更新版的维护。而OracleJDK的更新只面向付费用户。商业用户的通过钞票的投票，来选择和支持Oracle的JDK维护团队。



Java SE团队照看好未来，OpenJDK社区照看好现在，OracleJDK支持好商业用户。 这看起来是一个相当不做的模式。

有哪些生态的变化？

发布模式的变更，虽然有很多争议，但实质上带来了非常积极的变化，而且大都是好的变化。

Java社区活跃了

我能看到的第一个变化，是Java社区终于活跃起来了。



到2018年九月份，Java SE开源11年还要多了。我们看到的活跃在Java社区的开发者，大部分都是Oracle的研发人员，很少看到其他的贡献者。



其实，这个原因很简单。Java SE团队的成员似乎能解决一切问题，满足所有的迫切需求。社区里有问题，有需求，只要提问题就好了。大部分时候，总会有Java SE团队的成员站出来解决掉。Java社区的其他开发者，没有动手解决掉问题的迫切需求和动力。如果没有亲自动手，也很难提出高质量的问题，很难深入去理解Java的底层细节和基本原理。这像是一个很钝、很懒的迟缓反馈。



2018年到现在的一年半时间，我可以明确感受到Java社区的沸腾程度。这股积攒了十多年的研发力量，终于爆发了出来。这些力量来自于Redhat，来自于SAP，来自于阿里巴巴，来自于腾讯，来自于很多知名的、不知名的，团队的、个人的各种各样的开发者。这些开发者评估新版本的变更，贡献代码更新，协作评审、测试、调试代码变更。似乎一夜之间，Java社区的力量就被启动了。



比如说吧，之前的OpenJDK的邮件列表，我每天只能看到很少的邮件。而且这些邮件大都来自于Oracle的Java研发团队。现在，单单是JDK 8更新这一个邮件列表，每天都有几十封邮件，而且大部分邮件都来自于Oracle以外的开发者。很多问题的讨论，都有不同背景、不同地域、不同公司的开发者参与讨论。这在一年多以前，是不可想象的事情。

Java创新速度加快

Java SE团队照看好未来，这样的选择让Java SE团队的专家能够更有效地分配好、使用好他们的时间。这样，就能够让每一个小版本都有新意，每一个小版本都有提升。如果你认真研究下JDK 11以来发布的小版本，对比一下JDK 11之前的版本特性，你应该也可以感受到这种速度和质量的变化。

JDK专家队伍扩大

只靠阅读JDK的代码，是成不了JDK专家的。要成为专家，是需要把自己放进来，亲自动手贡献代码的。



我自己有一些印象比较深刻的人和事。



有一个刚毕业不久的小伙子，两三年以前，还只能问问简单的问题。后来，试着修复一些小问题。当时的代码，实在是读不下去的。提交上来的更新，几乎都要推倒了重新整理思路，每一行代码似乎都可以改一改。



也就是这两年，由于OpenJDK版本维护的需要，他做了大量的更新评估和维护。现在，他可以处理非常复杂的问题，领导复杂的更新和维护，已经是OpenJDK里的活跃用户和高质量的贡献者。这种成长的速度，是让人有点吃惊的。



OpenJDK版本维护，需要自己动手。而自己动手，能够让更多的开发者参与进来，成长为相关领域的专家。这就使社区成为一个快速、有效的反馈和学习环境。

更健壮的OpenJDK

很多人担心，没有了Java SE团队的照看，OpenJDK版本的质量会不会发生变形？ 这种担心是有道理的，也是应该的。可是，一件事往往是多种因素相互影响的结果。



经过一年多时间，当我回头看OpenJDK版本的质量时，我不仅没有了这种担心，还看到了更多的推动质量改进的因素。



但OpenJDK的版本不再控制在一家公司手里的时候，多种声音、多种需求就出现了。这些声音和需求，会推动着OpenJDK版本的持续地改进。



比如说，JFR是JDK 11的一个强大的功能。这个新功能虽然有很多的现实需求，但是由于涉及到大量的代码，一般情况下，是不会考虑整合到以前的更新版本里的。由于很多企业还在大量使用JDK 8，这就有了把JFR整合到JDK 8里的渴望。 包括阿里巴巴在内的很多开发者，一起推动了JFR在JDK 8的整合工作。 这实在是一个社区推动软件更新的一个典范。

个性化的JDK版本

JDK的缺省实现和设置，是一个多方平衡、调适的结果，大体只能做到兼顾大部分场景。可是有很多体量巨大的用户，他们有着特殊的需求，需要把JDK调整到最适合他们的生产力场景。



比如说，阿里巴巴就对JDK的性能有着苛刻的要求。这就需要深挖JDK的潜力，把JDK调适到最好的性能，最适合阿里巴巴的运行场景。于是，我们看到了阿里巴巴自己发布的Dragonwell，腾讯发布的Kona。这些基于OpenJDK的发布版，满足了不同客户的个性化需求。



自然地，这些个性化需求，也会催生很多创新，并且回馈给OpenJDK。这是一个多赢的局面。



最后，对于Java许可证变更这件事，我的想法是：

1. Java SE许可证的变化简化了用户的选择，没什么大不了的事情。

2. Java SE发布模式的变更，像一个蝴蝶扇动了翅膀，Java生态格局有了积极的变化。

3. OpenJDK社区的能力正在爆发，他们会是推动Java前进的一股不可或缺的力量。



好的，今天我们就聊到这儿。