Java发展轶事(202x)
2010-06-05 09:46:38 
阿炯
本文主要用于记录Java语言发展过程中的大事记，截止到2030年前。
Java规范第二次面临分裂危机
Java之父首度透露离开甲骨文原因-薪水太低
美法官裁定甲骨文JavaAPI不受版权保护
Oracle 正式发布 Java 22
Oracle开始严查Java许可，收割全球java开发使用者
Java规范第二次面临分裂危机
2010年6月上旬消息，这样的危机对于Java来说已经不是第一次了，在上个世纪90年代后期，也就是Java刚刚出现不长时间就遇到了第一次危机。当时微软为了跟SUN之间争夺 Java的事实标准权，开发了自己特有的版本Visual J++，并与其VS系列开发套件结合在一起，还提供了专有的扩展API。这一系列行为都背离了SUN对于Java规范的要求。这一纷争导致SUN与微软之间刻薄地批评对方，并对簿公堂。最用在2001年以SUN胜出结束，这也让微软彻底离开了Java阵营，从此与Java无缘。在该事件之后，也确立了 Java的使用原则，那就是SUN持有Java的标准权，无论哪个厂商，都必需遵守该标准。
在后来成立了的JCP组织，允许更多的厂商参与到Java的规范制定当中。JCP组织的出现，让IBM、Oracle很众多软件厂商有机会参与到Java的发展当中，使Java得到了十足的发展。如果当时因为微软与SUN之争，导致Java标准分裂，就不会有今天的成就。上一次危机已经过去10多年，今天新的危机有出现了。历史又一次重演。前几天VMWare与Google发表声明，一起进军云计算领域。并将Java作为首选开发语言，着名的Java开源框架Spring作为首选开发模型。看起来这视乎在为已经10多岁的Java注入新生力量。但是51CTO也敏锐的发现，VMWare与Google一系列动作之后，也为Java带来了标准分裂的危机。
尽管Google是开源以及开放网络标准的坚定支持者。但是在谈到Java标准问题的时候，却说他们采用的是一个小于标准的纯Java路线。也就是说Google不会支持全部的Java标准。只会支持一部分。如果把Java标准比喻成大树的话，Google支持的部分可能是一个树枝、也可能只是一个树叶。这个说法对于Google来说，已经有过类似的历史。在其开源Android平台上，采用的就是部分标准策略。在Android平台上，只支持Java基本语法和部分 API，并且必须采用Android特有的架构模式。更大的区别是，Android平台上的Java程序只是与标准Java程序在源代码级别兼容，编译结果根本不一样，这导致Java的最大特点，也就是一次编译到处运行成为空话。
在Google与VMWare联手进军云计算的声明中，关于Java EE规范问题，Google说，他们只会支持该规范的一个子集。也许在不久的将来，大家将会看到一个被阉割过的Java EE版本。至于在云计算平台上将采用什么样的虚拟机问题，还没有确切的消息。很可能Google版本的Java EE与Android平台上的Java SE一样，只是一个拥有Java外表的Java。有人也许会提出疑问，既然是这样，为什么Spring这样一个遵守Java规范的开源框架也会加入这一联盟，需要提醒大家的是，Spring的创始人本身也是一个Java EE规范的反对者，非常痛恨Java EE中的EJB以及重量级Web Service的人。其开发Spring的目的就是想改变Java EE的开发模式。
虽然现在还无法确定有多少企业打算吧他们的Java应用迁移到Google应用引擎下，但是从目前的数据来看，Google应用引擎社区注册用户只有不到5000人，这与数百万的Java开发者来说是一个个相当小的数字。两个事件对以一下，会让人觉得惊人的类似。不同的地方就是Google的策略比较柔和，并没有像微软哪项想彻底的改变Java。但是，需要承认的是，Google是一个非常强大的企业，强大到可以让一个Java 规范可用的子集变成一个事实上的标准子集。也就是说可让一个从大树上截取的树枝与大树处于同等的地位。
在这之前，Spring所做的也是类似的工作，其仅仅使用了Java EE的一个子集，但是没有Google做的深入彻底。如果Google对Java EE的做法与Android的手法类似，那么他就根本不必在乎谁持有Java的商标了，也不会在受任何限制，做到当时微软想做但是没有做到的事情。这一切的后果就是导致Java规范的分裂。随着规范之间的距离越来越远，Java开发者将面对像C++开发者所面对的同样的问题，虽然采用的是相同的程序语言，但是不同平台开发者之间几乎无法互相沟通和理解。
Java之父首度透露离开甲骨文原因-薪水太低
导读：《eWeek》网络版在2010年9月下旬刊登了对Java创始人詹姆斯·格斯林(James Gosling)的专访。格斯林在专访中谈到了此前一些未公开的内幕，包括他为何会在甲骨文收购Sun之后从甲骨文离职。
当格斯林领导他的团队，开发出Java语言和平台时，Sun正是一家如日中天的公司，而Java也被证明是一项革命性的技术。然而财务问题最终拖垮了Sun，甲骨文则成为Sun的救世主。许多人认为甲骨文收购Sun是正确的做法，然而对格斯林来说，这是完全错误的。
格斯林开发了Java，因此外界认为他应当受到尊重。然而格斯林表示，他从甲骨文得到的反应是完全相反的。在接受采访时，格斯林谈论了他离开甲骨文的原因，以及他认为甲骨文将把Java引向何方。
薪酬引发不满
今年4月，格斯林在博客中撰文，宣布从甲骨文辞职。他当时表示：“关于我离开的原因，这个问题很难说清。我所能提供的任何准确及诚实的信息都将带来危害，而不是帮助。”格斯林此次接受采访时谈到了更多细节。他表示，甲骨文藐视Sun的关键员工，将Sun原本制定项目和战略完全推翻。
格斯林表示：“导致我离开甲骨文的原因有很多，我的薪水也是因素之一。当我从他们那里拿到我的薪酬合同时，我试图在W-2表格中看看我的薪酬究竟是怎样，然而这让我震惊。他们只是从Sun复制了我的基本薪酬。”此前Sun的所有副总裁及以上级别管理人员都拥有与绩效挂钩的奖励。
格斯林指出：“如果我希望继续在甲骨文工作，那么我必须接受大幅降薪。”甲骨文一名发言人表示，该公司不会对格斯林的说法置评。
不过这还不是全部的原因。实际上，即使存在这样的困难，格斯林也决定继续在甲骨文工作。然而根据格斯林的说法，他遇到了另一个麻烦，即甲骨文内部没有高级工程师这样的职位，以对应格斯林原本在Sun的级别。格斯林表示：“在我的薪酬合同上，他们大幅下调了我的级别。”
Sun高管被架空
然而这也不是导致格斯林离开的最终原因。格斯林表示，甲骨文试图控制他。甲骨文收购了Sun，因此获得了Java，他们也拥有了Java的开发者及知识产权。因此甲骨文希望决定格斯林及其他人对Java的态度。
格斯林表示：“在甲骨文，我能决定的事情微乎其微。甲骨文是一家极度重视细节管理的公司。因此我和Java方面的同事无权决定任何事，我们的决策权不复存在。”
这导致格斯林在甲骨文的工作如同鸡肋。格斯林表示：“我的工作看起来就是登上舞台，成为为甲骨文服务的Java代言人。我不适合做这样的工作。”这一问题导致双方的关系最终破裂。格斯林表示，甲骨文在道德上带来挑战，而他本人已经受够了，因此决定不再为甲骨文工作。
更倾向加盟IBM
对于他是否希望Sun被IBM，而不是甲骨文收购时，格斯林表示，他与Sun董事长斯科特·麦克尼利(Scott McNealy)进行了激烈的争论。麦克尼利拿出了最终意见：尽管甲骨文可能更粗鲁，但IBM会进行更多的裁员。
记录显示，近年来IBM往往在收购后进行大规模裁员。在考虑了这一因素之后，Sun管理层决定推动与甲骨文的交易。格斯林表示，在宣布甲骨文和Sun合并之前，Sun已经进行了数轮裁员。
然而对格斯林本人而言，他更倾向于IBM，因为IBM往往给予技术型人才更多报酬。例如当IBM收购Rational Software时，该公司发现了Rational首席科学家、UML语言联合开发者格雷迪·布切(Grady Booch)的价值，并任命他为IBM技术委员。尽管布切常常在台前高谈阔论，但他仍然是IBM软件集团及研发部门之间的关键纽带，并且积极从事创新工 作。如果Sun被IBM收购，格斯林或许也将享受同样的待遇。
格斯林提到的细节管理问题在IBM内部或许也不存在。格斯林表示，他感到甲骨文CEO拉里·埃里森(Larry Ellison)几乎完全掌控了与Java相关的决策。很明显，IBM董事长兼CEO彭明盛(Sam Palmisano)不会干预被收购产品未来的运作，即使是像Sun这样的重大收购。然而甲骨文和IBM之间存在很大区别。
权力结构问题
格斯林认为，埃里森与体育大亨、美式橄榄球大联盟奥克兰突袭者队老板阿尔·戴维斯(Al Davis)类似。后者不断的聘请教练，并在选秀中招揽青年才俊，只是为了凸显他自己。不过与甲骨文不同，戴维斯和奥克兰突袭者队距离最终的成功还很远。
格斯林表示，尽管他并没有直接与埃里森打交道，然而埃里森“是令人毛骨悚然的人”。他表示：“Sun的所有高级管理人员都获得了巧妙的补偿。他们的职位保持不变，但他们失去了进行决策的能力。”
格斯林表示，令人毛骨悚然的不仅是埃里森本人，还包括甲骨文的权力结构。他表示，Sun当时计划租下位于加州圣克拉拉的Great America游乐场，让Sun的员工放松一天。麦克尼利和Sun CEO乔纳桑·施瓦茨(Jonathan Schwartz)已签字同意这一活动并拨出预算。然而在活动之前的几天，甲骨文联席总裁萨弗拉·卡兹(Safra Catz)得知了这一消息，并对其大肆攻击。
格斯林表示：“卡兹得知这一消息后大发雷霆。她表示甲骨文从没有过这种员工答谢活动，因此她迫使Sun取消这一活动。然而这并没有节约任何费用，因为费用已经花出去了。因此最终我们只能将门票捐给慈善机构。我们被迫放弃只是因为这么做不是‘甲骨文的方式’。但另一方面，甲骨文却拿出2亿美元赞助一条帆船。”
不看好甲骨文起诉谷歌
麦克尼利对甲骨文“粗鲁”的评价随后也得到体现。格斯林表示，他们早已料到甲骨文会就Android系统使用Java的问题对谷歌提起诉讼。他在4月份的博客文章中还表示，当Sun谈到Java当前的专利情况时，甲骨文的律师两眼放光。格斯林表示，无论这起诉讼最终的结果怎样，他都不会认为谷歌是蓄意这样做的。
对于谷歌，格斯林表示：“我们对他们所做的工作，以及工作的方式印象深刻。但是打官司的代价总是非常昂贵的，不仅仅是钱，也包括公司高管花费的时间。美国政府与微软之间的官司几乎浪费了我整整一年时间。”
格斯林还表示：“谷歌在公共关系方面有着光环，是全世界的宠儿。”他表示，起诉这样一家公司是Sun不会去做的。格斯林此前曾在另一篇博客文章中谈到Sun如何处理与Android之间的关系。
尽管已经离开甲骨文，但格斯林表示他并不关心Java在甲骨文领导下的命运。他表示：“我不是非常关心甲骨文领导下的Java，因为Java已经获得了自己的生命。甲骨文可以做的破坏性工作很少，因为他们的业务非常依赖Java。善待Java符合他们的利益。”不过格斯林认为，Java近期的发展可能会面临一些障碍，因为甲骨文“非常傲慢”。
Tasktop Technologies CEO米克·科尔斯滕(Mik Kersten)表示：“外界对于Java作为一个平台的命运感到担忧。对于在这一平台上进行开发的企业和机构来说，令人欣慰之处在于Java的规模很 大，已经超越任何一家单独的厂商。”
美法官裁定甲骨文Java API不受版权保护
在甲骨文诉谷歌侵犯Java版权及专利的案件中，所涉37个特定API(应用程序接口)是否受版权保护是一大争议问题。2012年6月上旬法官裁定甲骨文的那些API不受版权保护，这一裁决对甲骨文造成重大打击。
法官威廉·阿尔萨普(William Alsup)仅仅就所涉37个特定的API是否受版权保护作出裁决，但还没有解决API是否能够依照版权法获得版权保护这一更宽泛的问题。法官写道，“因此，甲骨文基于Google复制37个API包——其中包括结构、序列和组织——的申诉被驳回。”
法官指出，API包含有创意元素，但它还是一种精确的命令结构——符号集的实用功能，列出每个符号的预分配功能。根据美国版权法第102条(b)，这种命令结构属于一类操作的方法或系统，因此不受版权保护，复制命令结构是互操作性所必不可少的。法官的裁决对甲骨文而言是致命一击，但它很有可能提起上诉。
甲骨文控告谷歌Android侵犯其Java版权和专利。此前法院判定谷歌未侵犯甲骨文的Java专利。
阿尔萨普表示，“只要用于开发的特定代码是不同的，按照版权法，任何人都能自主编写自己的代码来执行同样的功能或者用于Java API的方法规范。”
甲骨文在一份声明中称要进行上诉。
以下是甲骨文对阿尔萨普的裁决的回应：甲骨文致力于保护Java，将它视为一个有价值的开发平台和一项有价值的知识产权。公司将就法官的裁决提出上诉，以维护Java，并持续支持由超过900万开发者和无数守法企业组成的广大Java社区。谷歌不能够免费使用所涉的API，因为使用Java规范一直都需要获得授权。法院对“互用性”的信任，忽视了一个无可争议的事实——谷歌刻意消除Android与所有其它Java平台之间的互用性。谷歌故意分化Java，违背“编写一次，随处运行”的承诺。该裁决如允许生效，将会削弱对美国创新发明的保护，大大加大打击世界各地的侵权行为以及维护知识产权的难度。
以下是谷歌对法官裁决的回应：法院的裁决维护了开发、互用计算语言构成软件开发必要基础的原则。这是对合作与创新而言美好的一天。
Oracle 正式发布 Java 22
Oracle于2024年3月下旬正式发布 Java 22，这是备受欢迎的编程语言和开发平台推出的全新版本。(Oracle JDK 22) 在性能、稳定性和安全性方面进行了数千种改进，包括对 Java 语言、其 API 和性能，以及 Java 开发工具包 (JDK) 中工具的增强功能，以帮助开发人员提高工作效率，推动企业加速创新和发展。全新版本的 JDK 更新和改进了 12 项 JDK 增强建议 (JEPs)。
JDK 22 将提供 OpenJDK Project Amber 的语言改进 (Statements before super […]、Unnamed Variables & Patterns、String Templates 以及 Implicitly Declared Classes 和 Instance Main Methods)；Project Panama 的改进 (Foreign Function 以及 Memory API 和 Vector API)；有关 Project Loom 的特性 (Structured Concurrency 和 Scoped Values)；核心库和工具功能 (Class-File API、Launch Multi-File Source-Code Programs、Stream Gatherers) 以及性能更新 (Region Pinning for G1)。
Java 22 提供的重要更新包括：
Project Amber 的特性
JEP 447
Statements before super(…)— 支持开发人员自由地表达构造器的行为。对于未引用正在创建的实例的语句，该语句也可以在调用显式构造器之前出现，让开发人员可以更自然地放置逻辑。该逻辑需要纳入辅助静态方法、辅助中间构造器或构造器参数中。该特性还将延续现有保证，即允许构造器在类实例化期间按自上而下的顺序运行，以帮助确保子类构造器中的代码不会干扰超类实例化。此外，此特性不需要对 Java Virtual Machine (JVM) 进行任何更改，并且仅依赖于 JVM 的当前能力来验证和执行在构造器中显式调用之前显示的代码。
JEP 456
Unnamed Variables & Patterns— 通过未命名的变量和模式来增强 Java 语言。在必须使用变量声明或嵌套模式，但又从未使用过的情况下，开发人员可以使用这些变量和模式来提高生产力。这种方法可以减少出错的机会，提高记录模式的可读性，并提高代码的可维护性。
JEP 459
String Templates（第二预览版）— 使包含运行时计算值的字符串更容易表达，简化 Java 程序的开发工作，同时提高将用户提供的值编写成字符串，并将字符串传递给其他系统的程序的安全性。此外，该特性还可提高参杂了表达式和文本的可读性，创建通过文字文本和嵌入表达式计算的非字符串值，而无需通过中间字符串表示形式传递。
JEP 463
Implicitly Declared Classes and Instance Main Methods（第二预览版）— 通过 Java 编程入门教程，学生无需了解为大型程序而设计的语言功能，即可顺利编写第一个程序，加快了上手速度。通过此特性，教育工作者可以循序渐进地介绍概念，学生也可以编写简化的单类程序声明，并随着个人技能的提升，无缝扩展程序并使用更高级的功能。
Project Loom 的特性
JEP 462
Structured Concurrency（第二预览版）— 通过引入用于结构化并发的 API，帮助开发人员简化错误处理和取消，并提高可观测性，进而鼓励更多人选择并发编程。该编程风格可以消除因取消和关闭而产生的常见风险，例如线程泄漏和取消延迟，以此提高并发代码的可观测性。
JEP 464
Scoped Values（第二预览版）— 支持开发人员在线程内和线程之间共享不可变数据，从而提高项目的易用性、可理解性、性能和稳健性。
Project Panama 的特性
JEP 454
Foreign Function & Memory API— 新推出的 API 使 Java 程序更容易与 Java 运行时之外的代码和数据互操作，从而帮助开发人员提高易用性、灵活性、安全性和性能。通过有效调用外部函数（即 Java Virtual Machine (JVM) 之外的代码），以及安全地访问外部内存（即不受 JVM 管理的内存），这个新的 API 支持 Java 程序在无需 Java Native Interface 的情况下调用本地库和处理原生数据。
JEP 460
Vector API（七次孵化阶段）— 引入 API 来表达向量计算，在运行时可靠地编译为支持的 CPU 架构上的向量指令，使开发人员获得优于等效标量计算的性能。
核心库和工具功能
JEP 457
Class-File API（预览版）— 通过提供用于解析、生成和转换 Java 类文件的标准 API，帮助开发人员提高工作效率。
JEP 458
Launch Multi-File Source-Code Programs— 支持开发人员通过增强 Java 应用启动器，选择是否以及何时需要配置构建工具，从而运行作为多个 Java 源代码文件提供的程序。
JEP 461
Stream Gatherers（预览版）— 通过增强 Stream API 来支持自定义中间操作，让流管道能以比现有内置中间操作更轻松的方式转换数据，从而帮助开发人员提高工作效率。此特性能够使流管道更灵活、更具表达力，允许自定义中间操作处理大小不限的流，帮助开发人员高效读取、写入和维护 Java 代码。
性能更新
JEP 423
Region Pinning for G1— 在原本需要暂停收集器的本机库调用期间，允许进行某些资源回收，有助于减少延迟。其中的原理是，在本机库调用期间，对需要禁止的对象以及仅 “固定” 包含这些对象的区域进行跟踪。如此一来，即使是在原本会禁止本机库调用的期间，未固定的区域也可以继续正常进行资源回收。
Java 22 是 Oracle 与全球 Java 开发人员社区成员通过 OpenJDK 社区 和 Java Community Process (JCP) 共同合作的成果。Java 22 除了推出了新的增强功能和特性，也获得 Java Management Service (JMS) 的支持，这是一项新的 Oracle 云基础设施远程软件服务 (Oracle Cloud Infrastructure, OCI) 原生服务，提供统一的控制台和仪表盘，帮助企业管理本地或云端的 Java 运行时和应用。
IDC 软件开发研究副总裁 Arnal Dayaratna 表示：经过近三十年发展，Java 能够支持各种用例的复杂开发任务，这种能力让该平台变得十分重要。Java 的多功能性和全面的工具集使其能够大规模支持生产级关键任务应用的开发，因此成为了生成式 AI 等创新用例的关键支持技术。
甲骨文公司 Java 平台高级副总裁兼 OpenJDK 管理委员会主席 Georges Saab 表示：Java 22 新的增强功能让更多开发人员能够快速、轻松地构建和交付功能丰富、可扩展且安全的应用，从而帮助全球各地的组织发展业务。这些增强功能可以简化应用开发，扩大 Java 的覆盖范围，以供不同技术水平的开发人员访问，帮助组织和开发人员创建各种新的应用和服务。
Oracle开始严查Java许可，收割全球java开发使用者
2024年在论坛里就看到一个新闻说“Oracle又再次对Java下手，开始严查Java许可，有企业连夜删除JDK”。7月在科技圈又看到有媒体报道，Oracle再次严查，对于Java许可和版权的审查越来越严格了。其实很早之前就有看到报道说，甲骨文公司Oracle已经开始将Java纳入其软件许可审查中，并且对一些公司的Java采用情况开启审计，目的是找出那些处于不合规边缘或已经违规的客户。之前主要还是针对一些小公司发出过审查函件，而现在，甚至包括财富200强在内的一些组织或公司都收到了来自Oracle有关审查方面的信件。
2023年上半年的时候，Oracle就曾发布过一个PDF格式的新版Java SE收费政策《Oracle Java SE Universal Subscription Global Price List (PDF)》。打开那个PDF，在里面可以看到Oracle新的Java SE通用订阅全球价目表：
表格底部还举了一个具体计费的例子。
比如说一个公司有2.8万名总雇员，里面可能包含有2.3万名全职、兼职、临时雇员，以及5000其他类型员工（比如说代理商、合约商、咨询顾问），那这个总价格是按如下方式进行计算：
28000 * 6.75$/月 * 12个月 = 2268000$/年
合着这个新的收费标准是直接基于公司里总的员工数来进行计算的，而不仅仅是使用Java SE的员工数。这样一来，可能就会使企业在相同软件的的使用情况下会多出不少费用，从而增加软件成本。不得不说Oracle接手之后把Java的商业化运作这块整得是明明白白的。
众所周知，其实Java最初是由Sun公司的詹姆斯·高斯林（James Gosling，后来也被称为Java之父）及其团队所研发的。并且最开始名字并不叫Java，而是被命名为：Oak，这个名字得自于 Gosling 想名字时看到了窗外的一棵橡树。就在 Gosling 的团队即将发布成果之前，又出了个小插曲——Oak 竟然是一个注册商标。Oak Technology（OAKT）是一家美国半导体芯片制造商，Oak 是其注册商标。既然不能叫Oak，那应该怎么命名好呢？
后来 Gosling 看见了同事桌上有一瓶咖啡，包装上写着 Java，于是灵感一现。至此，Java语言正式得名，并使用至今。1995年5月，Oak语言才更名为Java（印度尼西亚爪哇岛的英文名称，因盛产咖啡而闻名），并于当时的SunWorld大会上发布了JAVA 1.0，而且那句“Write Once，Run Anywhere”的slogan也是那时候推出的。此后Java语言一直由Sun公司来进行维护开发，一直到早期的JDK 7。2009年4月，Oracle以74亿美元现金收购了Sun公司，至此一代巨头基本没落。与此同时，Java商标也被列入Oracle麾下，成为了Oracle的重要资源。
众所周知，Oracle接手Java之后，就迅速开始了商业化之路的实践，也于后续推出了一系列调整和改革的操作。其实Oracle早在2017年9月就宣布将改变JDK版本发布周期。新版本发布周期中，一改原先以特性驱动的发布方式，而变成了以时间为驱动的版本迭代。也即：每6个月会发布一个新的Java版本，而每3年则会推出一个LTS版本。
而直到前段时间，Java 22都已经正式发布了。那针对Oracle这一系列动作，以及新的定价策略和订阅问题，有不少网友讨论道，那就不使用Oralce JDK，切换到OpenJDK，或者使用某些公司开源的第三方JDK。
众所周知，OpenJDK是一个基于GPLv2 许可的开源项目(https://github.com/openjdk/jdk)，自Java 7开始就是Java SE的官方参考实现。既然如此，也有不少企业或者组织基于OpenJDK从而构建了自己的JDK版本，这些往往都是基于OpenJDK源码，然后增加或者说定制一些自己的专属内容。比如像阿里的Dragonwell，腾讯的Kona，AWS的Amazon Corretto，以及Azul提供的Zulu JDK等等，都是这类典型的代表。它们都是各自根据自身的业务场景和业务需求并基于OpenJDK来打造推出的开源JDK发行版本，像这些也都是可以按需去选用的。
过80%的用户因成本等原因放弃 Oracle Java
Azul在2024年7月发布了一份全球 Oracle Java 使用、定价和迁移调查和报告，旨在评估 Java 社区对 Oracle 的定价、政策和 Java 支持的反应。报告基于来自全球 663 名经验丰富的 Java 专业人士的反馈，探讨了 Oracle Java 用户迁移到基于 OpenJDK 的替代方案的原因、迁移过程和时间的详细信息，以及支持和技术专业知识对于 OpenJDK 发行版的重要性。多年来 Oracle 在 Java 用户中的份额一直在下降，从 2020 年的 JDK 发行版市场的约 75% 下降到 2023 年的 42%。调查结果表明，86% 的 Oracle Java SE 用户正在或计划将其全部或部分 Java 应用程序从 Oracle 迁移出去。
具体原因包括成本、对开源的偏好、对 Oracle 正在进行的定价变化的不确定性以及 Java 使用审计的威胁。
成本：53% 的人认为 Oracle Java 太贵。
偏好开源替代品：47% 的人表示希望使用像 OpenJDK 这样的开源发行版。
不确定性：38% 的受访者指出 Oracle 的定价、许可和支持正在发生变化。
审计风险：25% 的人提到对 Oracle 可能进行的 Java 使用情况审计的担忧。
支持：24% 的人表示 Oracle 支持未能满足他们的期望。
大约三分之二的计划从 Oracle Java 迁移的受访者将在两年内完成迁移。在计划继续使用 Oracle Java 的 14% 的受访者中，约三分之一的人表示他们对 Oracle 的定价和政策感到满意。大多数已迁移的组织都对迁移过程、时间和结果感到满意，有三分之二的受访者表示从 Oracle Java 转向 OpenJDK 发行版帮助组织节省了成本。
75% 的受访者在一年内完成了向 OpenJDK 的迁移，23% 的受访者在不到三个月的时间内完成了迁移。84% 的受访者表示，迁移到 OpenJDK 发行版的过程符合预期；其中 41% 表示迁移过程比预期的要容易，43% 表示迁移过程按计划进行。
Java规范第二次面临分裂危机
Java之父首度透露离开甲骨文原因-薪水太低
美法官裁定甲骨文JavaAPI不受版权保护
Oracle 正式发布 Java 22
Oracle开始严查Java许可，收割全球java开发使用者
Java规范第二次面临分裂危机
2010年6月上旬消息，这样的危机对于Java来说已经不是第一次了，在上个世纪90年代后期，也就是Java刚刚出现不长时间就遇到了第一次危机。当时微软为了跟SUN之间争夺 Java的事实标准权，开发了自己特有的版本Visual J++，并与其VS系列开发套件结合在一起，还提供了专有的扩展API。这一系列行为都背离了SUN对于Java规范的要求。这一纷争导致SUN与微软之间刻薄地批评对方，并对簿公堂。最用在2001年以SUN胜出结束，这也让微软彻底离开了Java阵营，从此与Java无缘。在该事件之后，也确立了 Java的使用原则，那就是SUN持有Java的标准权，无论哪个厂商，都必需遵守该标准。
在后来成立了的JCP组织，允许更多的厂商参与到Java的规范制定当中。JCP组织的出现，让IBM、Oracle很众多软件厂商有机会参与到Java的发展当中，使Java得到了十足的发展。如果当时因为微软与SUN之争，导致Java标准分裂，就不会有今天的成就。上一次危机已经过去10多年，今天新的危机有出现了。历史又一次重演。前几天VMWare与Google发表声明，一起进军云计算领域。并将Java作为首选开发语言，着名的Java开源框架Spring作为首选开发模型。看起来这视乎在为已经10多岁的Java注入新生力量。但是51CTO也敏锐的发现，VMWare与Google一系列动作之后，也为Java带来了标准分裂的危机。
尽管Google是开源以及开放网络标准的坚定支持者。但是在谈到Java标准问题的时候，却说他们采用的是一个小于标准的纯Java路线。也就是说Google不会支持全部的Java标准。只会支持一部分。如果把Java标准比喻成大树的话，Google支持的部分可能是一个树枝、也可能只是一个树叶。这个说法对于Google来说，已经有过类似的历史。在其开源Android平台上，采用的就是部分标准策略。在Android平台上，只支持Java基本语法和部分 API，并且必须采用Android特有的架构模式。更大的区别是，Android平台上的Java程序只是与标准Java程序在源代码级别兼容，编译结果根本不一样，这导致Java的最大特点，也就是一次编译到处运行成为空话。
在Google与VMWare联手进军云计算的声明中，关于Java EE规范问题，Google说，他们只会支持该规范的一个子集。也许在不久的将来，大家将会看到一个被阉割过的Java EE版本。至于在云计算平台上将采用什么样的虚拟机问题，还没有确切的消息。很可能Google版本的Java EE与Android平台上的Java SE一样，只是一个拥有Java外表的Java。有人也许会提出疑问，既然是这样，为什么Spring这样一个遵守Java规范的开源框架也会加入这一联盟，需要提醒大家的是，Spring的创始人本身也是一个Java EE规范的反对者，非常痛恨Java EE中的EJB以及重量级Web Service的人。其开发Spring的目的就是想改变Java EE的开发模式。
虽然现在还无法确定有多少企业打算吧他们的Java应用迁移到Google应用引擎下，但是从目前的数据来看，Google应用引擎社区注册用户只有不到5000人，这与数百万的Java开发者来说是一个个相当小的数字。两个事件对以一下，会让人觉得惊人的类似。不同的地方就是Google的策略比较柔和，并没有像微软哪项想彻底的改变Java。但是，需要承认的是，Google是一个非常强大的企业，强大到可以让一个Java 规范可用的子集变成一个事实上的标准子集。也就是说可让一个从大树上截取的树枝与大树处于同等的地位。
在这之前，Spring所做的也是类似的工作，其仅仅使用了Java EE的一个子集，但是没有Google做的深入彻底。如果Google对Java EE的做法与Android的手法类似，那么他就根本不必在乎谁持有Java的商标了，也不会在受任何限制，做到当时微软想做但是没有做到的事情。这一切的后果就是导致Java规范的分裂。随着规范之间的距离越来越远，Java开发者将面对像C++开发者所面对的同样的问题，虽然采用的是相同的程序语言，但是不同平台开发者之间几乎无法互相沟通和理解。
Java之父首度透露离开甲骨文原因-薪水太低
导读：《eWeek》网络版在2010年9月下旬刊登了对Java创始人詹姆斯·格斯林(James Gosling)的专访。格斯林在专访中谈到了此前一些未公开的内幕，包括他为何会在甲骨文收购Sun之后从甲骨文离职。
当格斯林领导他的团队，开发出Java语言和平台时，Sun正是一家如日中天的公司，而Java也被证明是一项革命性的技术。然而财务问题最终拖垮了Sun，甲骨文则成为Sun的救世主。许多人认为甲骨文收购Sun是正确的做法，然而对格斯林来说，这是完全错误的。
格斯林开发了Java，因此外界认为他应当受到尊重。然而格斯林表示，他从甲骨文得到的反应是完全相反的。在接受采访时，格斯林谈论了他离开甲骨文的原因，以及他认为甲骨文将把Java引向何方。
薪酬引发不满
今年4月，格斯林在博客中撰文，宣布从甲骨文辞职。他当时表示：“关于我离开的原因，这个问题很难说清。我所能提供的任何准确及诚实的信息都将带来危害，而不是帮助。”格斯林此次接受采访时谈到了更多细节。他表示，甲骨文藐视Sun的关键员工，将Sun原本制定项目和战略完全推翻。
格斯林表示：“导致我离开甲骨文的原因有很多，我的薪水也是因素之一。当我从他们那里拿到我的薪酬合同时，我试图在W-2表格中看看我的薪酬究竟是怎样，然而这让我震惊。他们只是从Sun复制了我的基本薪酬。”此前Sun的所有副总裁及以上级别管理人员都拥有与绩效挂钩的奖励。
格斯林指出：“如果我希望继续在甲骨文工作，那么我必须接受大幅降薪。”甲骨文一名发言人表示，该公司不会对格斯林的说法置评。
不过这还不是全部的原因。实际上，即使存在这样的困难，格斯林也决定继续在甲骨文工作。然而根据格斯林的说法，他遇到了另一个麻烦，即甲骨文内部没有高级工程师这样的职位，以对应格斯林原本在Sun的级别。格斯林表示：“在我的薪酬合同上，他们大幅下调了我的级别。”
Sun高管被架空
然而这也不是导致格斯林离开的最终原因。格斯林表示，甲骨文试图控制他。甲骨文收购了Sun，因此获得了Java，他们也拥有了Java的开发者及知识产权。因此甲骨文希望决定格斯林及其他人对Java的态度。
格斯林表示：“在甲骨文，我能决定的事情微乎其微。甲骨文是一家极度重视细节管理的公司。因此我和Java方面的同事无权决定任何事，我们的决策权不复存在。”
这导致格斯林在甲骨文的工作如同鸡肋。格斯林表示：“我的工作看起来就是登上舞台，成为为甲骨文服务的Java代言人。我不适合做这样的工作。”这一问题导致双方的关系最终破裂。格斯林表示，甲骨文在道德上带来挑战，而他本人已经受够了，因此决定不再为甲骨文工作。
更倾向加盟IBM
对于他是否希望Sun被IBM，而不是甲骨文收购时，格斯林表示，他与Sun董事长斯科特·麦克尼利(Scott McNealy)进行了激烈的争论。麦克尼利拿出了最终意见：尽管甲骨文可能更粗鲁，但IBM会进行更多的裁员。
记录显示，近年来IBM往往在收购后进行大规模裁员。在考虑了这一因素之后，Sun管理层决定推动与甲骨文的交易。格斯林表示，在宣布甲骨文和Sun合并之前，Sun已经进行了数轮裁员。
然而对格斯林本人而言，他更倾向于IBM，因为IBM往往给予技术型人才更多报酬。例如当IBM收购Rational Software时，该公司发现了Rational首席科学家、UML语言联合开发者格雷迪·布切(Grady Booch)的价值，并任命他为IBM技术委员。尽管布切常常在台前高谈阔论，但他仍然是IBM软件集团及研发部门之间的关键纽带，并且积极从事创新工 作。如果Sun被IBM收购，格斯林或许也将享受同样的待遇。
格斯林提到的细节管理问题在IBM内部或许也不存在。格斯林表示，他感到甲骨文CEO拉里·埃里森(Larry Ellison)几乎完全掌控了与Java相关的决策。很明显，IBM董事长兼CEO彭明盛(Sam Palmisano)不会干预被收购产品未来的运作，即使是像Sun这样的重大收购。然而甲骨文和IBM之间存在很大区别。
权力结构问题
格斯林认为，埃里森与体育大亨、美式橄榄球大联盟奥克兰突袭者队老板阿尔·戴维斯(Al Davis)类似。后者不断的聘请教练，并在选秀中招揽青年才俊，只是为了凸显他自己。不过与甲骨文不同，戴维斯和奥克兰突袭者队距离最终的成功还很远。
格斯林表示，尽管他并没有直接与埃里森打交道，然而埃里森“是令人毛骨悚然的人”。他表示：“Sun的所有高级管理人员都获得了巧妙的补偿。他们的职位保持不变，但他们失去了进行决策的能力。”
格斯林表示，令人毛骨悚然的不仅是埃里森本人，还包括甲骨文的权力结构。他表示，Sun当时计划租下位于加州圣克拉拉的Great America游乐场，让Sun的员工放松一天。麦克尼利和Sun CEO乔纳桑·施瓦茨(Jonathan Schwartz)已签字同意这一活动并拨出预算。然而在活动之前的几天，甲骨文联席总裁萨弗拉·卡兹(Safra Catz)得知了这一消息，并对其大肆攻击。
格斯林表示：“卡兹得知这一消息后大发雷霆。她表示甲骨文从没有过这种员工答谢活动，因此她迫使Sun取消这一活动。然而这并没有节约任何费用，因为费用已经花出去了。因此最终我们只能将门票捐给慈善机构。我们被迫放弃只是因为这么做不是‘甲骨文的方式’。但另一方面，甲骨文却拿出2亿美元赞助一条帆船。”
不看好甲骨文起诉谷歌
麦克尼利对甲骨文“粗鲁”的评价随后也得到体现。格斯林表示，他们早已料到甲骨文会就Android系统使用Java的问题对谷歌提起诉讼。他在4月份的博客文章中还表示，当Sun谈到Java当前的专利情况时，甲骨文的律师两眼放光。格斯林表示，无论这起诉讼最终的结果怎样，他都不会认为谷歌是蓄意这样做的。
对于谷歌，格斯林表示：“我们对他们所做的工作，以及工作的方式印象深刻。但是打官司的代价总是非常昂贵的，不仅仅是钱，也包括公司高管花费的时间。美国政府与微软之间的官司几乎浪费了我整整一年时间。”
格斯林还表示：“谷歌在公共关系方面有着光环，是全世界的宠儿。”他表示，起诉这样一家公司是Sun不会去做的。格斯林此前曾在另一篇博客文章中谈到Sun如何处理与Android之间的关系。
尽管已经离开甲骨文，但格斯林表示他并不关心Java在甲骨文领导下的命运。他表示：“我不是非常关心甲骨文领导下的Java，因为Java已经获得了自己的生命。甲骨文可以做的破坏性工作很少，因为他们的业务非常依赖Java。善待Java符合他们的利益。”不过格斯林认为，Java近期的发展可能会面临一些障碍，因为甲骨文“非常傲慢”。
Tasktop Technologies CEO米克·科尔斯滕(Mik Kersten)表示：“外界对于Java作为一个平台的命运感到担忧。对于在这一平台上进行开发的企业和机构来说，令人欣慰之处在于Java的规模很 大，已经超越任何一家单独的厂商。”
美法官裁定甲骨文Java API不受版权保护
在甲骨文诉谷歌侵犯Java版权及专利的案件中，所涉37个特定API(应用程序接口)是否受版权保护是一大争议问题。2012年6月上旬法官裁定甲骨文的那些API不受版权保护，这一裁决对甲骨文造成重大打击。
法官威廉·阿尔萨普(William Alsup)仅仅就所涉37个特定的API是否受版权保护作出裁决，但还没有解决API是否能够依照版权法获得版权保护这一更宽泛的问题。法官写道，“因此，甲骨文基于Google复制37个API包——其中包括结构、序列和组织——的申诉被驳回。”
法官指出，API包含有创意元素，但它还是一种精确的命令结构——符号集的实用功能，列出每个符号的预分配功能。根据美国版权法第102条(b)，这种命令结构属于一类操作的方法或系统，因此不受版权保护，复制命令结构是互操作性所必不可少的。法官的裁决对甲骨文而言是致命一击，但它很有可能提起上诉。
甲骨文控告谷歌Android侵犯其Java版权和专利。此前法院判定谷歌未侵犯甲骨文的Java专利。
阿尔萨普表示，“只要用于开发的特定代码是不同的，按照版权法，任何人都能自主编写自己的代码来执行同样的功能或者用于Java API的方法规范。”
甲骨文在一份声明中称要进行上诉。
以下是甲骨文对阿尔萨普的裁决的回应：甲骨文致力于保护Java，将它视为一个有价值的开发平台和一项有价值的知识产权。公司将就法官的裁决提出上诉，以维护Java，并持续支持由超过900万开发者和无数守法企业组成的广大Java社区。谷歌不能够免费使用所涉的API，因为使用Java规范一直都需要获得授权。法院对“互用性”的信任，忽视了一个无可争议的事实——谷歌刻意消除Android与所有其它Java平台之间的互用性。谷歌故意分化Java，违背“编写一次，随处运行”的承诺。该裁决如允许生效，将会削弱对美国创新发明的保护，大大加大打击世界各地的侵权行为以及维护知识产权的难度。
以下是谷歌对法官裁决的回应：法院的裁决维护了开发、互用计算语言构成软件开发必要基础的原则。这是对合作与创新而言美好的一天。
Oracle 正式发布 Java 22
Oracle于2024年3月下旬正式发布 Java 22，这是备受欢迎的编程语言和开发平台推出的全新版本。(Oracle JDK 22) 在性能、稳定性和安全性方面进行了数千种改进，包括对 Java 语言、其 API 和性能，以及 Java 开发工具包 (JDK) 中工具的增强功能，以帮助开发人员提高工作效率，推动企业加速创新和发展。全新版本的 JDK 更新和改进了 12 项 JDK 增强建议 (JEPs)。
JDK 22 将提供 OpenJDK Project Amber 的语言改进 (Statements before super […]、Unnamed Variables & Patterns、String Templates 以及 Implicitly Declared Classes 和 Instance Main Methods)；Project Panama 的改进 (Foreign Function 以及 Memory API 和 Vector API)；有关 Project Loom 的特性 (Structured Concurrency 和 Scoped Values)；核心库和工具功能 (Class-File API、Launch Multi-File Source-Code Programs、Stream Gatherers) 以及性能更新 (Region Pinning for G1)。
Java 22 提供的重要更新包括：
Project Amber 的特性
JEP 447
Statements before super(…)— 支持开发人员自由地表达构造器的行为。对于未引用正在创建的实例的语句，该语句也可以在调用显式构造器之前出现，让开发人员可以更自然地放置逻辑。该逻辑需要纳入辅助静态方法、辅助中间构造器或构造器参数中。该特性还将延续现有保证，即允许构造器在类实例化期间按自上而下的顺序运行，以帮助确保子类构造器中的代码不会干扰超类实例化。此外，此特性不需要对 Java Virtual Machine (JVM) 进行任何更改，并且仅依赖于 JVM 的当前能力来验证和执行在构造器中显式调用之前显示的代码。
JEP 456
Unnamed Variables & Patterns— 通过未命名的变量和模式来增强 Java 语言。在必须使用变量声明或嵌套模式，但又从未使用过的情况下，开发人员可以使用这些变量和模式来提高生产力。这种方法可以减少出错的机会，提高记录模式的可读性，并提高代码的可维护性。
JEP 459
String Templates（第二预览版）— 使包含运行时计算值的字符串更容易表达，简化 Java 程序的开发工作，同时提高将用户提供的值编写成字符串，并将字符串传递给其他系统的程序的安全性。此外，该特性还可提高参杂了表达式和文本的可读性，创建通过文字文本和嵌入表达式计算的非字符串值，而无需通过中间字符串表示形式传递。
JEP 463
Implicitly Declared Classes and Instance Main Methods（第二预览版）— 通过 Java 编程入门教程，学生无需了解为大型程序而设计的语言功能，即可顺利编写第一个程序，加快了上手速度。通过此特性，教育工作者可以循序渐进地介绍概念，学生也可以编写简化的单类程序声明，并随着个人技能的提升，无缝扩展程序并使用更高级的功能。
Project Loom 的特性
JEP 462
Structured Concurrency（第二预览版）— 通过引入用于结构化并发的 API，帮助开发人员简化错误处理和取消，并提高可观测性，进而鼓励更多人选择并发编程。该编程风格可以消除因取消和关闭而产生的常见风险，例如线程泄漏和取消延迟，以此提高并发代码的可观测性。
JEP 464
Scoped Values（第二预览版）— 支持开发人员在线程内和线程之间共享不可变数据，从而提高项目的易用性、可理解性、性能和稳健性。
Project Panama 的特性
JEP 454
Foreign Function & Memory API— 新推出的 API 使 Java 程序更容易与 Java 运行时之外的代码和数据互操作，从而帮助开发人员提高易用性、灵活性、安全性和性能。通过有效调用外部函数（即 Java Virtual Machine (JVM) 之外的代码），以及安全地访问外部内存（即不受 JVM 管理的内存），这个新的 API 支持 Java 程序在无需 Java Native Interface 的情况下调用本地库和处理原生数据。
JEP 460
Vector API（七次孵化阶段）— 引入 API 来表达向量计算，在运行时可靠地编译为支持的 CPU 架构上的向量指令，使开发人员获得优于等效标量计算的性能。
核心库和工具功能
JEP 457
Class-File API（预览版）— 通过提供用于解析、生成和转换 Java 类文件的标准 API，帮助开发人员提高工作效率。
JEP 458
Launch Multi-File Source-Code Programs— 支持开发人员通过增强 Java 应用启动器，选择是否以及何时需要配置构建工具，从而运行作为多个 Java 源代码文件提供的程序。
JEP 461
Stream Gatherers（预览版）— 通过增强 Stream API 来支持自定义中间操作，让流管道能以比现有内置中间操作更轻松的方式转换数据，从而帮助开发人员提高工作效率。此特性能够使流管道更灵活、更具表达力，允许自定义中间操作处理大小不限的流，帮助开发人员高效读取、写入和维护 Java 代码。
性能更新
JEP 423
Region Pinning for G1— 在原本需要暂停收集器的本机库调用期间，允许进行某些资源回收，有助于减少延迟。其中的原理是，在本机库调用期间，对需要禁止的对象以及仅 “固定” 包含这些对象的区域进行跟踪。如此一来，即使是在原本会禁止本机库调用的期间，未固定的区域也可以继续正常进行资源回收。
Java 22 是 Oracle 与全球 Java 开发人员社区成员通过 OpenJDK 社区 和 Java Community Process (JCP) 共同合作的成果。Java 22 除了推出了新的增强功能和特性，也获得 Java Management Service (JMS) 的支持，这是一项新的 Oracle 云基础设施远程软件服务 (Oracle Cloud Infrastructure, OCI) 原生服务，提供统一的控制台和仪表盘，帮助企业管理本地或云端的 Java 运行时和应用。
IDC 软件开发研究副总裁 Arnal Dayaratna 表示：经过近三十年发展，Java 能够支持各种用例的复杂开发任务，这种能力让该平台变得十分重要。Java 的多功能性和全面的工具集使其能够大规模支持生产级关键任务应用的开发，因此成为了生成式 AI 等创新用例的关键支持技术。
甲骨文公司 Java 平台高级副总裁兼 OpenJDK 管理委员会主席 Georges Saab 表示：Java 22 新的增强功能让更多开发人员能够快速、轻松地构建和交付功能丰富、可扩展且安全的应用，从而帮助全球各地的组织发展业务。这些增强功能可以简化应用开发，扩大 Java 的覆盖范围，以供不同技术水平的开发人员访问，帮助组织和开发人员创建各种新的应用和服务。
Oracle开始严查Java许可，收割全球java开发使用者
2024年在论坛里就看到一个新闻说“Oracle又再次对Java下手，开始严查Java许可，有企业连夜删除JDK”。7月在科技圈又看到有媒体报道，Oracle再次严查，对于Java许可和版权的审查越来越严格了。其实很早之前就有看到报道说，甲骨文公司Oracle已经开始将Java纳入其软件许可审查中，并且对一些公司的Java采用情况开启审计，目的是找出那些处于不合规边缘或已经违规的客户。之前主要还是针对一些小公司发出过审查函件，而现在，甚至包括财富200强在内的一些组织或公司都收到了来自Oracle有关审查方面的信件。
2023年上半年的时候，Oracle就曾发布过一个PDF格式的新版Java SE收费政策《Oracle Java SE Universal Subscription Global Price List (PDF)》。打开那个PDF，在里面可以看到Oracle新的Java SE通用订阅全球价目表：
表格底部还举了一个具体计费的例子。
比如说一个公司有2.8万名总雇员，里面可能包含有2.3万名全职、兼职、临时雇员，以及5000其他类型员工（比如说代理商、合约商、咨询顾问），那这个总价格是按如下方式进行计算：
28000 * 6.75$/月 * 12个月 = 2268000$/年
合着这个新的收费标准是直接基于公司里总的员工数来进行计算的，而不仅仅是使用Java SE的员工数。这样一来，可能就会使企业在相同软件的的使用情况下会多出不少费用，从而增加软件成本。不得不说Oracle接手之后把Java的商业化运作这块整得是明明白白的。
众所周知，其实Java最初是由Sun公司的詹姆斯·高斯林（James Gosling，后来也被称为Java之父）及其团队所研发的。并且最开始名字并不叫Java，而是被命名为：Oak，这个名字得自于 Gosling 想名字时看到了窗外的一棵橡树。就在 Gosling 的团队即将发布成果之前，又出了个小插曲——Oak 竟然是一个注册商标。Oak Technology（OAKT）是一家美国半导体芯片制造商，Oak 是其注册商标。既然不能叫Oak，那应该怎么命名好呢？
后来 Gosling 看见了同事桌上有一瓶咖啡，包装上写着 Java，于是灵感一现。至此，Java语言正式得名，并使用至今。1995年5月，Oak语言才更名为Java（印度尼西亚爪哇岛的英文名称，因盛产咖啡而闻名），并于当时的SunWorld大会上发布了JAVA 1.0，而且那句“Write Once，Run Anywhere”的slogan也是那时候推出的。此后Java语言一直由Sun公司来进行维护开发，一直到早期的JDK 7。2009年4月，Oracle以74亿美元现金收购了Sun公司，至此一代巨头基本没落。与此同时，Java商标也被列入Oracle麾下，成为了Oracle的重要资源。
众所周知，Oracle接手Java之后，就迅速开始了商业化之路的实践，也于后续推出了一系列调整和改革的操作。其实Oracle早在2017年9月就宣布将改变JDK版本发布周期。新版本发布周期中，一改原先以特性驱动的发布方式，而变成了以时间为驱动的版本迭代。也即：每6个月会发布一个新的Java版本，而每3年则会推出一个LTS版本。
而直到前段时间，Java 22都已经正式发布了。那针对Oracle这一系列动作，以及新的定价策略和订阅问题，有不少网友讨论道，那就不使用Oralce JDK，切换到OpenJDK，或者使用某些公司开源的第三方JDK。
众所周知，OpenJDK是一个基于GPLv2 许可的开源项目(https://github.com/openjdk/jdk)，自Java 7开始就是Java SE的官方参考实现。既然如此，也有不少企业或者组织基于OpenJDK从而构建了自己的JDK版本，这些往往都是基于OpenJDK源码，然后增加或者说定制一些自己的专属内容。比如像阿里的Dragonwell，腾讯的Kona，AWS的Amazon Corretto，以及Azul提供的Zulu JDK等等，都是这类典型的代表。它们都是各自根据自身的业务场景和业务需求并基于OpenJDK来打造推出的开源JDK发行版本，像这些也都是可以按需去选用的。
过80%的用户因成本等原因放弃 Oracle Java
Azul在2024年7月发布了一份全球 Oracle Java 使用、定价和迁移调查和报告，旨在评估 Java 社区对 Oracle 的定价、政策和 Java 支持的反应。报告基于来自全球 663 名经验丰富的 Java 专业人士的反馈，探讨了 Oracle Java 用户迁移到基于 OpenJDK 的替代方案的原因、迁移过程和时间的详细信息，以及支持和技术专业知识对于 OpenJDK 发行版的重要性。多年来 Oracle 在 Java 用户中的份额一直在下降，从 2020 年的 JDK 发行版市场的约 75% 下降到 2023 年的 42%。调查结果表明，86% 的 Oracle Java SE 用户正在或计划将其全部或部分 Java 应用程序从 Oracle 迁移出去。
具体原因包括成本、对开源的偏好、对 Oracle 正在进行的定价变化的不确定性以及 Java 使用审计的威胁。
成本：53% 的人认为 Oracle Java 太贵。
偏好开源替代品：47% 的人表示希望使用像 OpenJDK 这样的开源发行版。
不确定性：38% 的受访者指出 Oracle 的定价、许可和支持正在发生变化。
审计风险：25% 的人提到对 Oracle 可能进行的 Java 使用情况审计的担忧。
支持：24% 的人表示 Oracle 支持未能满足他们的期望。
大约三分之二的计划从 Oracle Java 迁移的受访者将在两年内完成迁移。在计划继续使用 Oracle Java 的 14% 的受访者中，约三分之一的人表示他们对 Oracle 的定价和政策感到满意。大多数已迁移的组织都对迁移过程、时间和结果感到满意，有三分之二的受访者表示从 Oracle Java 转向 OpenJDK 发行版帮助组织节省了成本。
75% 的受访者在一年内完成了向 OpenJDK 的迁移，23% 的受访者在不到三个月的时间内完成了迁移。84% 的受访者表示，迁移到 OpenJDK 发行版的过程符合预期；其中 41% 表示迁移过程比预期的要容易，43% 表示迁移过程按计划进行。