甲骨文业务再次动手，欲对 Java 加以扼杀

原文链接：Hacker 时间

甲骨文公司对于 Java EE 的沉默态度已经将开发者社区的不信任感激发到白热化程度。

相信大家早已经发现，甲骨文公司正悄悄从社区驱动型技术项目中撤出资金援助与开发资源，只留客户与合作伙伴对其进行推动与维护。理由自然非常明显，甲骨文无法从这类项目中获取充足的经济收益。

这类套路对于甲骨文已经不是新鲜事，其向来会通过此种方式将开源项目转化为专有技术成果，当初的 OpenSolaris 与 OpenOffice.org 都经历过同样的命运。而这一次，噩运降临到了 Java 头上——更具体地讲，是 Java 企业版（即 Jave EE ）。作为服务器端 Java 技术，其已经成为无数互联网与商务应用程序中的重要组成部分。事实上， Java EE 甚至在众多非 Java 应用中也占有一席之地。

最近几个月以来，甲骨文公司的律师团正在法庭上针对 Android Dalvik 编程语言中使用 Java 接口一事猛击谷歌，而这无疑会给甲骨文自身的 Java 开发进度造成影响。在 Java EE 方面，甲骨文公司则采取了全面停滞的态度。这种死一般的沉寂令众多为 Java 平台做出贡献以及参与 Java 技术社区的企业客户感到极度不安——其中也包含相当一部分甲骨文公司的大型客户。

甲骨文公司内部负责 Java EE 项目的员工告知社区内的其他成员，他们已经接到命令转而进行其它方面的研发。另外还有一份来自各位为 Java 平台开发 fork 版本的 Java EE 开发者的公告，指出他们决定将自己的实现成果拆分出来，即放弃与甲骨文于六年前收购得来的、已经拥有二十年发展历史的 Java 平台间的兼容能力。目前甲骨文公司对于 Java EE 的发展规划仍然一言不发，完全无视 Java 标准社区成员们的激烈情绪。

“他们的行为无异于玩火，” Java 社区进程执行委员会独立当选成员 Geir Magnusson 在接受采访时表示。“这实在令人震惊——正是这家公司让我们越发思念已经消失的 Sun 。”

Magnusson 指出，甲骨文公司如今的作法类似于当初的“苏俄政权”，其整个决策流程完全不具备透明性。不过根据熟知甲骨文方面内情的消息人士透露，目前公司董事长 Larry Ellison 对全部争论都心知肚明。而为了在法庭上与谷歌公司正面对抗，甲骨文方面的高管已经撤销了对 Java EE 技术团队的资金援助。

而伴随着甲骨文公司的闷声作大死，除了 Java EE 之外，整个 Java 社区也开始对其进行口诛笔伐。一个名为 Java EE 护卫队的组织目前就在进行公共关系交涉与请愿活动，旨在向甲骨文施加压力以督促其继续推动 Java EE 发展或者将其设置为免费项目。不过由于甲骨文公司对于 Java 拥有极为明确的知识产权掌握能力，因此其胜算极为渺茫——特别是考虑到甲骨文还在对谷歌方面进行起诉。

已经于今年 3 月离职的甲骨文公司前 Java 布道者 Reza Rahman 如今成为 Java EE 护卫队组织的一名发言人。“截至目前，我们从 Java EE 规范负责人处获得的惟一回应就是，他们无法继续推进相关工作，”他在采访中指出。“他们甚至没有透露还有哪些进一步工作可以进行。”

Rahman 认为，如果甲骨文公司继续对 Java EE 进行雪藏，那么“ Java 社区与整个行业都将面临着短期与长期风险。 Java 与 Java EE 已经成为全球大部分 IT 领域所普遍依赖的技术手段。” Java 生态系统是在过去二十年中逐步建立完成的，其开放标准也得到了众多厂商的支持，“亦关乎到我们每个人的生计，”他解释称。如果没有持续注资与管理作为支撑， Rahman 表示“ Java 生态系统中的各个部分都将随时间推移而不断弱化，而且整个 IT 领域都将在短期内受到影响。”

在报告这一事件的同时，相关媒体还试图与数十名熟知 Java 开发工作的前任与现任甲骨文公司员工取得联系。另外，其还接触了多位甲骨文客户，希望了解他们对此事的意见。然而截至目前尚未有任何确切结论传出，在大多数情况下受访者担心自己的言论可能被甲骨文方面的律师团抓到把柄。

另外，媒体方面还多次与甲骨文公司的媒体关系团队进行交涉，然而得到的回应除了语音助理之外再无其它，语音邮件与电子邮件也毫无回音。在联系到一名直接负责该平台的评论人员之后，对方的答复非常简单：“抱歉，不接受采访。”

Java 开发者噩梦之四

甲骨文公司的贪婪天性早已经成为业界的笑柄。在 2015 年的 JavaOne 大会上，前任 Sun Micosystems 公司 CEO Scott McNealy 就在 Java 二十周年纪念活动中放出了一段视频，提出极为讽刺的“ Java 开发者的十二大噩梦”，而其中第四条正是“你热爱开源软件与分享精神，但却在给甲骨文干活。”

这一条令在场的 Java 开发人员们捧腹不已，但个中辛酸恐怕只有这些从业者才能体会。鉴于甲骨文公司以往在处理开源项目时的恶劣表现，特别是一路搞垮的众多技术成果，人们不禁要为 Java 的命运捏一把汗。就在 JavaOne 大会结束后不久，甲骨文公司的表现就印证了开发者们的担忧——其在实质上停止了推出 Java 的下一企业版本，而 Java SE 9 作为下一代核心版本的发布日期也被延后至 2017 年。

视频长 2 分 25 秒，建议在 Wi-Fi 环境下打开。前任 Sun Microsystems 公司董事长兼 CEO Scott McNealy 在去年十月召开的 JavaOne 大会上向 Java 开发者们公布了一系列坏消息。

甲骨文方面长久以来一直坚持扮演着技术大反派的角色，特别是在收购一 Sun Microsystems 并获得了其下各开源软件的所有权之后。从交易公布的那一刻开始，很多人就担心 Sun 公司执着于推动开源项目发展的精神会被破坏殆尽，最终成为甲骨文实现供应商锁定的另一种手段。而包括 XML 标准联合缔造者 Tim Bray 在内的多位 Sun 公司内部开源人才也在收购完成前选择离职。

然而事实证明大家的担忧并非空穴来风。甲骨文公司很快榨干了 Sun 旗下各开源方案的剩余价值，并迅速叫停了 OpenSolaris 操作系统的升级工作。在过去三年当中，甲骨文公司通过一系列举措对那些无法实现盈利或者主要由开源社区负责支持的项目进行了打压：

甲骨文与开源项目间的恩怨纠葛

2009 年 12 月， MySQL 缔造者 Ulf Michael “ Monty ” Widenius 发起请愿活动，要求欧盟监管机构阻止甲骨文收购 MySQL 的持有方 Sun 公司。 Widenius 预测称，甲骨文公司一旦完成收购，将很快对 MySQL 中的部分组件进行闭源。

2010 年 1 月，甲骨文公司完成对 Sun Microsystems 的收购。

2010 年 2 月，甲骨文公司将 OpenSolaris 移出产品路线图。

2010 年 3 月，开源负责人 Simon Phipps 离开 Sun/甲骨文公司。

2010 年 4 月， Java 之父 James Gosling 离开甲骨文公司。他随后将该公司形容为“对道德的挑战”。

2010 年 8 月，甲骨文公司发布备忘录，告知员工 OpenSolaris 将被中止，而 Solaris 与 ZFS 则被“关闭”； OpenSolaris 理事会被解散； OpenSolaris 与 ZFS “完全开放” fork 版本 Illumos 启动；多位 MySQL 技术团队成员跳槽前往 Rackspace 公司，加入 MySQL 另一 fork 版本 Drizzle 的开发项目。

2010 年 9 月， OpenOffice.org 社区成员考虑到 OpenSolaris 的开发前景与甲骨文对开发者规模的缩减而建立 The Document 基金会，旨在针对甲骨文旗下品牌开发 LibreOffice fork 。基金会成立后，他们曾邀请甲骨文加入成为其成员。

2010 年 10 月，甲骨文公司以“利益冲突”为由要求部分 The Document 基金会成员离开 OpenOffice.org 项目，同时拒绝加入该组织； LibreOffice 正式启动并以 fork 形式进行开发；甲骨文公司对原 Sun Grid Engine 高性能计算平台进行闭源，同时将开源维护人员转移至 Open Grid Scheduler 项目。（四个月后，整个 Grid 团队离开甲骨文并加入 Univa 。）

2010 年 12 月， Apache 基金会在甲骨文公司拒绝将 Apache 技术兼容套件许可纳入 Java 的 Apache Harmony 开源实现方案之后，决定辞去 Java 社区进程执行董事职务。

2011 年 1 月，甲骨文公司注册“ Hudson ”商标，即开源 Java 持续集成服务器平台的名称（社区投票将该项目重新命名为‘ Jenkins ’）。甲骨文公司此后继续内部开发自己的“ Hudson ”项目。

2011 年 4 月，甲骨文公司停止对 OpenOffice.org 与 OracleOpenOffice 的开发。两个月之后，该公司将代码捐赠予 Apache 。

2011 年 9 月，甲骨文公司宣称将发布 MySQL 的专有扩展版本，且该项目将不再以完全开源形式出现，而选择“开放内核”模式。

2013 年 6 月，甲骨文公司将 Berkeley DB 的开源版本许可由 BSD 类公共许可切换为 Affero GPL 许可，其要求用户将自身应用的源代码提供给任何通过网络与之联系的对象，同时在代码中遵循 GPL v.3 或者 APGL 许可。此举被广泛视为一种威胁行为，意味着甲骨文要求客户购买其商用许可来构建自定义应用，而这无疑给 Berkeley DB 造成了致命打击。

视频长 64 分 3 秒，建议在 Wi-Fi 环境下打开。 Joyent 公司的 Bryan Cantrill 向 Larry Ellison 大唱颂歌——前者目前负责 Illumos ， OpenSolaris 的一套 fork 版本。

夺取所有权

即使大规模削减开源项目投入力度，甲骨文公司仍然在为 Java 提供资金。事实上，作为独立企业运营的 Sun 公司在其最后阶段已经无力维护 Java 项目，甲骨文的介入则让其重新恢复了生机。

“ Java SE 其实真的很不错，” Eclipse 基金会执行理事、前任甲骨文公司副总裁兼 Java 社区进程（简称 JCP ）执行委员会成员 Mike Milinkovich 表示。“我们多年来一直停滞在 Java 6 时代，甲骨文方面接过了火炬并将其传递至 Java 7 与 Java 8 ，不久的未来还将出现 Java 9 。我认为他们在重构建这套平台并立足于 Sun 的开发基础加以改进方面做出了卓越的贡献。”

至少到目前为止，对 Java SE 最新版本的开发投入仍在继续——即 Java SE 9 ，代号为 Jigsaw 项目。这一迭代版本将对 Java 运行时进行模块化改造，同时使其更易于对接嵌入式设备。“ Java SE9 版本的重要性是毋庸置疑的，” Milinkovich 解释道。“因此，大家至少不应对甲骨文公司在 Java SE 身上的投入与领导能力有所非议。”

不过除了这部分投入之外，甲骨文公司也对 Java 的发展议程加以直接控制。甲骨文公司员工几乎接掌了与 Java 相关的全部提议规范，同时为 OpenJDK 的开发提供了大多数人员供应——其属于 Java SE 平台核心的开源参考实现方案。“ OpenJDK 是一套开源社区，” Milinkovich 表示。“但其并未实现供应商中立性，或者说无法在这方面与 Apach 或 Eclipse 相媲美。”

这种自上而下的控制已经引发了先前 Java 社区成员的广泛反对。作为 Java 的缔造者， 2010 年离开甲骨文的 James Gosling 在他的离职信中写道，“我能说的就是，在这里靠谱与诚实的行为只会受到抨击而非鼓励。”他随后在接受采访时表示，甲骨文公司的 Java 团队管理层不愿出让任何决策权。 Gosling 当时扮演的角色就像一位参加体育会展的退休球员，换言之而像是吉祥物而非核心技术人员。

几个月之后，甲骨文公司对 Java 开源命运的全面掌控让 Apache 基金会放弃了其在 JCP EC 中的席位。与当初的 Sun 公司不同，甲骨文方面拒绝向 Apache Harmony 开放 Java 虚拟机（简称 NVM ）出售技术兼容套件（简称 TCK ）。结果就是，甲骨文公司禁止 Apache 将其 Harmony 项目称为“ Java ”。

当时 Magnusson 正是 Apache 基金会在 JCP 的代表。他回忆称，甲骨文公司的决定确实出乎所有人的意料。“甲骨文方面直到收购 Sun 之前，都与我们站在同一阵营，”他解释道。“他们也是我们购买 TCK 的最大支持者之一。”

Apache 基金会通过投票方式抨击了 Java SE 7 的规范设置，而这无疑挑战了甲骨文公司的领导权。 Apache 方面宣称，甲骨文公司违反了 Java 社区进程本身的执行章程。“甲骨文公司拒绝针对任何合理性及责任问题向欧盟委员会做出回应，”时任 Apache 市场营销与宣传副总裁的 Sally Khudairi 表示。

锁定

甲骨文公司不断否决着要求对 Java 授权方式做出变更的各类申请。在最新一轮尝试中，技术社区要求对 JCP 的结构进行重组，但却被甲骨文公司的律师们拒绝。该法务团队警告称，任何针对授权许可做出的变更都可能引发严重后果，而与此同时谷歌也正因此而麻烦缠身。

另外，甲骨文公司的 OpenJDK 开发者们也在极力阻止 JCP 对 Java 标准的治理。这群开发者们在未经 JCP 许可的前提下直接为该平台创建了一系列新型组件。 JCP EC 与部分 OpenJDK 社区的非甲骨文成员就此展开据理力争，因为他们担心 JCP 会最终被甲骨文架空为毫无实际掌控能力的傀儡。

“随着越来越多新的开发方案被纳入到 OpenJDK 这套开源项目中来， JCP 在领导 Java 发展方面的价值已经被不断削弱，” Milinkovich 指出。尽管他在 JCP 担任职务，但 Milinkovich 仍然认为这算不上什么“大事”。

“作为运营开源社区的参与者，我认为这方面工作的价值就在于开放，”他表示。“不过确实需要针对一部分问题思考解决办法，包括 OpenJDK 社区的角色、开源的未来发展以及标准层面的变化等等。”

除了 JCP 方面的担忧之外，关于 Java EE 的非议之声则更值得关注。群众的不满开始于甲骨文公司停止 GlassFish 的商用支持与内部开发——其为 Java EE 的开源版本，并曾作为该平台的参考实现方案。尽管失去了商用支持， Open Glassfish 仍然曾经由甲骨文方面的员工进行推动。 Java EE 7 以及 GlassFish 开放方案随后于 2013 年 6 月 12 日推出。

而在接下来的一年中， Jave EE 似乎也得到了推动—— 2014 年年内，大部分活跃 Java 规范请求都集中在 Java EE 领域。在 2014 年的 JavaOne 大会上，甲骨文与 JCP 正式发布了 Java EE 8 。双方还设定了发展目标，其规范方针直接部署至 2016 年 9 月。

CEO 对云计算全力以赴

2015 年，甲骨文公司瞄准了其业务新支点，即云服务的销售力度，并计划从 Java 开发工作中划分出相当一部分预算——特别是 Jave EE 与 GlassFish 团队。就在那个时候，甲骨文公司正式宣布 Java EE 8 发展路线图被推迟到“ 2017 年上半年”。

同年 8 月， Java EE 团队由于数个开发项目存在问题而被直接叫停。甲骨文公司高管团队在探讨之后，认为数据库与中间件产品在 2015 年 8 月的当季度中营收表现不佳，并随后关闭了 Java EE 开发项目。甲骨文公司高管决定进一步推进自身云业务，同时辞退了原本负责开发事务的高级副总裁兼 Java EE 支持者 Cameron Purdy 。有报道称，这是因为 Purdy 强烈要求甲骨文方面恢复 Java EE 团队的资金投入。

Purdy 并未对这一说法做出任何评论，不过在当时的一篇推文中，他开玩笑地表示甲骨文公司放他回家之后，他可以考虑参选美国总统。

此次裁员外加业务优先级的变动也直接体现在了各 Java 项目，特别是 Java EE 项目当中。此后得到解决的问题数量开始骤减，多数项目的代码提交量也大幅降低。 Java Server Faces （简称 JSF ）的新规范号称直到 2016 年第一季度才能与广大用户见面，但事实证明其截至当下仍踪迹全无。

在同年 4 月的 JCP 执行委员会会议上， Java EE 进度缺失被提入了议事日程。代表伦敦 Java 社区的 Martijn Verburg 表示，针对 Java EE 的工作早在上年 11 月份就已经告停。“就目前的情况看，甲骨文领导下的 Java EE JSR 明显已经没有了继续发展的迹象，” Verburg 表示。在会议纪要中同时提到，“甲骨文公司的几位规范事务负责人也明确表示，他们无法再在 JSR 项目身上投入任何时间与精力，而是被分配到了其它项目当中。”

坚决不予回应

甲骨文方面坚决不予回应的态度“正对 Java 社区与生态系统造成严重的损害，” Verburg 强调称。他同时补充道，“有关各方”正在积极讨论 Java EE 的未来发展并“考虑接管 Java EE 的领导工作”。由于缺少甲骨文方面的官方引导，各企业不得不利用自己的专有框架满足各实际需求，例如在 Java 社区中实现微服务支持能力。

“我们需要甲骨文公司给出的官方声明，” Verburg 指出。委员会中的富士通公司代表 Mike DeNicola 也对此表示赞同。如果甲骨文公司一直不对 JCP EC 就 Java EE 提出的公开声明做出回应，那么其会“严重影响到甲骨文在 JCP 中的声誉，” DeNicola 告诉我们。

来自甲骨文公司的 JCP 主席 Patrick Curran 表示，他“一定会将 EC 内部的态度与意见传达给甲骨文管理团队。” Curran 同时建议称，“我们会等待并观望‘分裂集团’关于 Java EE 的最终决定”。

截至目前，甲骨文公司仍未发表公开声明。相关社区则对此感到非常无奈。甚至包括部分在 JCP 拥有代表的金融服务企业——例如瑞士信贷——也开始表示高度关切。 Java EE 护卫队（也是 JCP 会议上的主要‘分裂集团’代表）已经启动了 Change.org 抗议网站，意在收集来自技术人员的请愿意见。最近，在 JCP 执行委员会会议上， Verburg 提出了已经愈发普遍的观点。甲骨文公司对于社交意见视若无睹的态度，已经基本证明“其不再关心 Java 生态系统的支持事务。”

Verburg 指出，他的公司未来将不再使用 Java EE ，因为其无法随甲骨文中止项目发展所带来的隐患。而根据会议记要， Magnusson 也指出“ JCP EC 成员已经公开声明称，他们不承诺在未来继续使用 Java EE 。”

然而，事件目前仍然处于僵持状态。甲骨文公司继续保持沉默，拒绝针对 JCP 的未来规划发表任何意见。缺少官方引导让 Java EE 社区不得不积极猜测甲骨文的意图，并被迫为最糟糕的结果做好准备。

Milinkovich 认为，发生这一切的根源在于，甲骨文就是甲骨文。“甲骨文公司最擅长的手段——先不论其好坏——就是制定并坚守决策，”他指出。而由于甲骨文公司的巨大体量，这类决策恐怕要持续相当长的一段时间。“我可以想象，甲骨文方面内部正在就此进行研讨，我也希望在今年的 JavaOne 大会上，社区能够通过交流敦促其完成决策——因为我认为如果无法在 JavaOne 上给出任何与 Java EE 发展路线图相关的情报，相关领域将瞬间爆炸。”

游戏结束

甲骨文公司其实有着大量相当充分的理由以继续坚持对 Java EE 的控制——其中最重要的就是，甲骨文自身也有很多软件产品与服务依赖于 Java EE 。尽管 Java EE 并不像 Java SE 在甲骨文的发展战略中占有重要地位，但其仍然间接为超过七成的营收做出贡献，具体包括软件与支持许可销售。

Java EE 护卫队的 Rahman 表示，他真心希望甲骨文方面能够回应该组织与整个社区提出的质疑。“需要强调的是，我们的努力从数周前才真正开始，”他指出。“在此之前，我们一直在尝试组织社区以及除甲骨文外的其它主要供应商，例如 IBM 与红帽。甲骨文公司应该还有很多时间跟余地来调整其行动方针。”

展望未来，该护卫队希望了解甲骨文公司是否还将继续作为 Java EE 的合作伙伴而存在。如果甲骨文方面选择退出，那么 Rahman 认为还会有其它厂商愿意接手 Java EE 。“ JCP 中的其它厂商，例如 IBM 与红帽，都能够承担起这份责任，”他表示。“这些厂商也都向甲骨文传达了目前状况的紧迫性，并表示问题需要尽快得到解决。他们也愿意帮助甲骨文收拾这堆烂摊子。”

然而也有不少人认为，甲骨文公司不可能针对目前的压力做出回应。“我认为他们的努力很难收到实际效果，” Magnusson 坦言。“甲骨文公司绝不是那种愿意任他人摆布的企业。”

当然，甲骨文公司可能只是决定暂时搁置 Java EE ，而且不会让任何人夺走其所有权……但由此产生的影响将远远超出企业级 Java 社区。事实上，目前甲骨文对于 Java 项目的态度之所以受到广泛关注，是因为 Java 已经被视为最完美的物联网实现工具。

甲骨文公司目前最理想的选择， Rahman 建议道，“就是将整套 Java 平台捐赠给 Eclipse 基金会、 Apache 、 ECMA 或者 W3C 这类组织。在那里，其它厂商以及技术社区都能够参与进来并推动其发展。”不过甲骨文公司真的会心甘情愿地将自家技术成果拱手让人吗？

Milinkovich 对其可能性提出了质疑。“我认为甲骨文公司几乎不可能将 Java 交给其它组织进行自由开源，”他解释称。“这是因为甲骨文需要对其股东负责，而将一项价值数十亿美元的资产凭空进行开源是无法接受的。而且我们也不可能指望着一拍脑袋进行开源， Java 面临的种种难题就能迎刃而解……这显然不切实际。事实上，具体解决方案应该更为细化，其核心内容不只是进行开源，而是考虑如何利用开源手段治理项目并满足技术社区的实际需求。”

考虑到甲骨文公司仍然需要 Java 企业资源支撑其云项目，可能其计划围绕内部云服务对 Java 企业版进行大规模调整。如果甲骨文公司不再允许 JCP 染指 Java EE ，那么该项目的最终命运也许会同 LibreOffice 一样。

而在最糟糕的情况下，甲骨文公司可能决定不再开发 Java EE 并拒绝任何企业或者组织接手该平台的后续开发。对于这样的情况， Magnusson 提出了一个简单的问题：“甲骨文公司是否认为这种坐以待毙且鼓励竞争对手推出替代性方案的作法真的对自身有利？如果选择这种方式，竞争对手是否可能从中获得助益？换言之，其可不可以继续推动项目以实现对竞争对手的打压？”

鉴于甲骨文公司以往一直对竞争对手采取寸土必争的战略，因此这种“我没有、你也不能有”的决定倒并非全无可能。不过这也会对其现有业务产生重大影响，例如疏远了那些支持甲骨文内部部署软件业务的客户。而竞争对手则能够借此拿出足以吸引这部分受众的方案。“我很难想象 IBM 这类公司会如此对待客户，” Magnusson 指出。

Java 启示录

如果甲骨文公司仍然以消极方式应对这一切，那么推出速度已经相当缓慢的 Java 安全补丁将趋于停滞，这意味着 Java EE 组件将遭受安全漏洞的影响。数以千计的服务器与云应用都将最终尝到恶果，并不得不寻求 Java servlets 以及其它内置 Java EE 组件作为替代方案。 Rahman 表示，如果真的出现这样的情况，那么“作为最后的手段，已经有众多厂商在讨论如何在甲骨文公司与 JCP 缺席的情况下建立起多厂商 Java API ，”他解释道。“到那个时候，我们的组织将加入相关工作。”

出于这些原因的考虑，看起来甲骨文公司更可能会吸收其它 Java 社区进程组织的成员在 Java EE 的开发工作中充当“规范领导者”，同时继续保持自身对 Java SE 的掌控能力。“ Java SE 拥有极为出色的质量，” Magnusson 表示。“其对生态系统有着强大的控制力，而且能够以不同的方式将 SE 资产转化为经济收益。”由于 Java EE 独立于 Java SE 核心之外单独起效，因此甲骨文公司仍然能够在 IBM 或者红帽等厂商接管 Java EE 规范制定权后继续保证对 Java 平台发展的总体控制能力。最终，甲骨文公司仍不会被排除在外。

Rahman 认为，甲骨文公司也有着明确的财务理由来继续推进 Java EE 发展——特别是考虑到该平台能够帮助甲骨文方面获得云业务成功。“我认为掌握 Java 能够让甲骨文的云方案吸引更多开发者并获得客户与业界的信任，”他指出。“对于 Java 这类获得极大成功的技术方案的拥有者，将其引入云端简直就是种必然的结果。”

然而，说服甲骨文公司相信其中有利可图的过程也许相当困难。由于该公司正在与谷歌方面就知识产权问题进行诉讼，进一步推动项目发展可能会在法律层面给甲骨文对 Java 的索赔资格产生负面影响。而目前的请愿活动也因此很难起到什么实际效果。正如 Sun 公司前任首席开源官兼开源倡议前任总裁 Simon Phipps 在 Twitter 上所提到，“一切无法对营收产生影响的行为，都不可能得到甲骨文方面的重视。”

考虑到甲骨文公司的利润正不断上升，再加上该公司的两位联合首席执行官分别占据目前技术业界高管薪酬榜的冠、亚军，相信业界呼声很难吸引到其注意。换言之，在出现确凿的经济影响证据之前， Java EE 仍将保持目前半死不活的状态。

本文翻译自： http://arstechnica.com/information-technology/2016/07/how-oracles-business-as-usual-is-threatening-to-kill-java/1/