java和oracle_Oracle和Java生态系统

java和oracle

在经历了无可否认的艰难开端之后，包括Doug Lea（他仍然活跃在OpenJDK中）和Apache软件基金会的JCP都高调辞职，Oracle做出了巨大的努力，以重新参与更广泛的Java生态系统这一主题。它在最近的JavaOne会议上谈到了这一点。 该公司正在努力与Java用户组负责人和Java倡导者进行互动，OpenJDK项目的成员正在不断增加，并且该公司正在努力改革Java社区流程以提高透明度。 该公司还发布了针对Java 8和Java 9的清晰明确的Java路线图。但是，问题仍然存在。

JCP.next：改革Java社区流程

Java Community Process通过主席Patrick Curran领导的一系列举措，旨在提高其透明度和敏捷性。 JSR 348是Oracle对JCP计划进行的一系列改革中的第一个，已经通过了最终批准投票。 它代表相对较小的变化，但仍然是重要的一步，要求将来所有专家组都使用公共邮件列表和公共问题跟踪器在公共场所开展所有业务。 Java.net将用于提供核心基础结构。 柯兰告诉我们

我将JSR 348作为java.net项目运行，并且运行良好-我们所需的一切就在那里。 我希望许多规范主管（可能还有所有Oracle规范主管）同样依赖于java.net。

类似的规则也适用于执行委员会，该委员会已经发布了其所有会议记录和会议资料，但现在需要至少举行一次公开的面对面会议，据Curran称，该会议通常在JavaOne举行，和两次公开电话会议。 还要求EC创建公共邮件列表以征询社区的反馈。 EC仍可以进入私人会话。 柯兰告诉我们

我认为这是欧共体应保留的一种选择，但这种选择应很少使用（实际上是这样）。 我们上一次进入非公开会议的时间是2010年9月，当时我们讨论了计划为JavaOne进行的发布，但我们希望在活动结束之前保持机密。

此外，JSR 348要求发布任何加入专家组的请求，并定义处理专家组成员或规范负责人未履行职责的情况的正式程序，以及对未出席的执行委员会成员的处罚会议。 摘自EC常规规则文件 （PDF）

• 连续两次错过会议（无论是电话会议还是面对面会议）都会导致所有尚未开始的JSR投票和EC投票失去投票特权。 失去投票特权的EC成员不能提出动议或反对。 连续两次参加会议后，特权将重新获得。
• 连续五个月错过一次会议，或者连续十二个月错过所有会议的三分之二以上，将导致EC成员资格丢失。
• PMO应向EC提供定期的出勤报告，并向有可能失去会员资格的人发出警告。
• 在特殊情况下，根据具体情况确定，欧委会可能会免除上述任何一种处罚。

最终，348引入了JSR的超时，因此，它们必须在定义的时间限制内到达流程的各个阶段，否则将面临关闭。 来自Java Community Process的2.8版文档

如果JSR在完成其JSR批准投票后的9个月内没有开始“早期草案审查”，或者在首次提交“早期草案”之后的12个月内没有开始公共审查，或者在开始进行公共审查的12个月内没有达到最终发布，则除非同意在特殊情况下可以证明延误，否则EC应该启动JSR续签。

除此之外，Oracle还计划另外两个JSR。 第一个计划将合并为两个JCP执行委员会。 目前，Java ME由一个执行委员会代表，而Java SE和EE由第二个执行委员会代表，鉴于Oracle明确表示要合并Java SE和ME，这一立场意义不大。 此更改应使整个过程更高效，并且还可能有助于促进Java生态系统不同部分之间的协同作用。

第二个JSR将更多地参与其中，因为它将研究与IP和许可权有关的复杂问题，这些问题是Sun Microsystems与Apache Software Foundation之间争执的核心，最终导致Apache离开JCP。 柯兰告诉我们

在处理JSR 348时，我们创建了一个列表，这些列表被认为超出了该JSR的范围。 这将用作我们关于后续JSR讨论的起点，但是当然，我们还没有决定实际解决哪个问题。

潜在冲突的一个领域是规范导致TCK使用的许可条款，这些许可条款由JCP参与协议控制，通常称为JSPA （PDF文档）。 JSPA管理IP问题，并要求公平访问TCK，并包含RAND语言。 InfoQ知道规范负责人可以选择收取TCK费用，尽管Curran告诉我们这并不完全正确

JCP规范的实现者可以选择。 他们可以按照免版税条款创建独立（无尘室）实现，或者如果他们希望以源代码或二进制形式并入参考实现中的元素，则可以按照RAND（合理和非歧视）条款许可必要的权利，提前披露。 请注意，无论哪种情况，实施者都必须许可TCK，以证明实施是兼容的。 RAND许可条款（预先披露）也可能在这里适用。

令人鼓舞的是，Oracle解决了JCP中的某些问题，并且还有其他可喜的迹象。 在JavaOne上，Oracle指出，今年对执行委员会进行公开投票的候选人有5位-Azul，CloudBees（尽管应该指出的是，Oracle前副总裁，JCP的长期成员史蒂夫·哈里斯（Steve Harris），最近移居CloudBees，担任产品高级副总裁，Terracotta，Twitter和Central Central Java Users Group。 最终，共有9名候选人参加了选举，这是一段时间以来最强的候选人，而Azul和Twitter是成功的候选人。 关于选举的更多分析可以在这里找到。 很高兴看到Oracle在此过程中鼓励除了ISV之外的Java用户组的参与。

OpenJDK的

自从Oracle接管了许多公司加入该项目以来，OpenJDK开展了大量活动。 过去一年中，新公司包括Apple，Azul Systems，IBM，SAP和Twitter。 完整的参与者名单令人印象深刻 。

Twitter可能尤其值得一提，因为它不是独立软件开发商，这是唐纳德·史密斯（Donald Smith）最近在其博客中指出的观点

在我看来，有三波参与开源项目的浪潮。 首先，它通常由ISV和同一行业的其他ISV发起。 如果该项目非常利基，或没有真正蓬勃发展，那就足够了。 但是，如果成功，并且该项目是面向平台/基础架构的，那么我们应该期望看到第二波参与者，这些参与者主要是软件公司，但是软件许可证不是产品本身。 Twitter就是一个很好的例子– Twitter是软件，但软件许可证不是产品。 除此之外，如果项目继续成功，我们应该看到非软件公司的第三阶段参与。 对于软件至关重要的公司，但在很大程度上并不是产品。 更多面向消费者的组织，其中软件是达到目标的手段。 我在想银行，保险公司，汽车制造商等。

当然，比谁注册加入更有趣的是他们可能会做出的贡献。 IBM在JavaOne 2011上宣布，除其他事项外，它将开始一个项目，以实现Jigsaw / OSGi互操作性。 Twitter的Chris Aniszczyk 表示 ，该公司计划“在JVM中围绕垃圾回收的性能和指标收集方面做出贡献”，Azul Systems的CTO Gil Tene告诉我们，该公司将寻求对HotSpot VM做出改进本身，例如对锁和线程模型的增强。

就实际贡献而言，OpenJDK社区TCK许可协议（以下称OCTLA）是关键文档，因此，令人惊讶的是发现Java 7的OCTLA在Java 7交付后六个月内发布了（请参阅此处 ）。 当我们在本文中与Tene交谈时，Tene强调了TCK的重要性

我们很高兴参与OpenJDK并为之做出贡献。 很高兴看到Oracle兑现他们的承诺，使其他人能够有意义地参与OpenJDK项目。 大量的贡献需要严格的兼容性测试，并且Oracle最近为将OpenJDK TCK提供给其他几个第三方使用的举动对于OpenJDK和整个Java Community Process都是至关重要的积极推动因素。

在提供TCK及其随附的许可证之前，由于多种原因，很难看到外部贡献者如何在平台上工作。 一方面，如果不能定期测试和验证任何大小的更改都不会破坏兼容性，那么开发周期就会变得不切实际地延长。 此外，即使是单个社区成员提出并贡献的最小的一线错误修复，也将受益于在提交之前以及在项目提交者必须考虑并浪费宝贵的资源进行评估之前，对完整的TCK进行测试。 而且，TCK对于保持兼容性至关重要。OpenJDK许可条款没有固有的内在含义，可以防止某人运输未经TCK测试验证的代码，从而冒着平台破裂和碎片的风险。

房间里的Android形大象

尽管Oracle正在努力与开发人员进行互动，但该公司决定就其Java for Android使用Google起诉Google的决定在同一团体中造成了很多弊病，无论实际诉讼是非是非。 在某种程度上，这反映了Java开发人员对Java在移动领域中的重要性日益感到不安。 尽管Java ME是Java的早期成功故事，并且仍在大量电话中使用，但由Apple领导的以iPhone和iPad为代表的当前智能电话和平板电脑的兴起很大程度上将Java ME视为无关紧要。在太空中。 作为Java ME的长期支持者，诺基亚一直很感兴趣，但已将重点转移到Windows Mobile。 同样困扰着黑莓制造商RIM，后者正从Java ME转向基于QNX的新操作系统，并以本机C / C ++作为首选开发语言。 在这种情况下，Android对于Java变得异常重要。

在这种情况下，OpenJDK贡献协议（OCA）是一个有趣的文档。 它定义了一些显而易见的事情，例如阐明GPL权利并断言所贡献的代码不存在问题，但它还做了其他事情：它允许Oracle将代码带入其商业产品以及GPL领域之外，并将其用于所需的任何目的（包括根据非GPL条款将其再许可给IBM之类的商业公司）。 这样的规定远非唯一：MySQL在被Sun收购之前就以类似的方式工作。 这也是必不可少的。 没有它，Oracle将被迫拆分代码，仅在封闭的一侧进行开发，并且，如果他们愿意的话，只能在下游进行开发。 这样的流程实际上将使任何第三方都无法为OpenJDK做出贡献，因为将这样的代码接受到项目中必然会（与许可条款一起）将其从Oracle的商业工作中派生出来。 如果发生这种情况，OpenJDK就会落伍了。

也许更重要的是，OCA并没有以任何方式限制OpenJDK代码的下游使用。 控制OpenJDK代码的唯一许可证是GPLv2 +类路径。 OCA唯一的网关是对上游OpenJDK项目的公认贡献。 如果有人想开发OpenJDK代码并仅在GPL下维护其代码（无需在OCA下将该代码段许可回Oracle），他们可以自由地这样做，他们可以按照自己想要的任何方式进行分发，甚至可以参考它是“源自OpenJDK代码库”还是“基于OpenJDK源代码”。

签署OCA不会阻止非基于OCA的开发。 OCA只是为OpenJDK项目做出实际贡献的工具。 它仅适用于根据协议明确贡献的特定代码，并且不排除不会在上游集成到OpenJDK中的纯GPL代码的正交开发。 换句话说，社区成员可以潜在地决定在OCA下做出贡献（例如，修复错误），同时保留其他部分，例如学术项目，尝试在较大的模块更改下进行试验，以及在纯GPL下进行大型手术，如果他们愿意的话。 。 除非稍后做出贡献，否则这些部分将永远不会成为上游OpenJDK的一部分。

在Oracle与谷歌在Android上发生争执的情况下，人们普遍认为Oracle不允许人们将OpenJDK用于嵌入式和移动设备，而是希望从OEM那里收取许可收入。 尽管Sun（并且大概是现在的Oracle）确实对第三方的商业许可证有使用限制，并且实际上在很大程度上是为Java开发付费的，但OpenJDK代码许可证没有这种限制。 换句话说，Google所需要做的就是发布基于OpenJDK的Android版本，并将其保持在GPLv2许可下。 争论的重点是Apache和Google能够在GPLv2框架之外构建内容，并且围绕着“使用范围”限制提出了建议：Oracle，在他们之前Sun一直拒绝在除classpath例外的GPLv2之外的开放源代码许可下，对Java源代码进行许可，而没有使用范围的限制。 Apache和Google想要做的是获取Java源代码（和/或使用TCK来测试干净的Java源代码，例如Harmony项目），并以替代许可证（例如Apache V2）提供它。

这也是IBM的立场，直到去年发生重大变化。 Oracle和IBM似乎达成了某种长期协议，同意在没有GPLv2限制的情况下将相同的OpenJDK代码许可回给他们-在OCA允许下Oracle可以在商业上做这件事-尽管在InfoQ与Oracle联系时，Oracle拒绝评论。 假设我们是正确的，那么这样的协议将意味着IBM不必担心其商业产品中的GPL污染：他们和其他人公开地为OpenJDK做出了贡献，让Oracle通过OCA重新许可代码，然后IBM获得了收益。通过为此目的已经达成的协议在商业上获得实质上相同代码的许可。 从理论上讲，Google可以达成类似的协议。

结论

尽管Google可以在理论上达成共识，但Oracle决定就Android的IP侵权而寻求搜索公司的决定充满了风险。 就像微软以类似的理由被Sun起诉.NET一样，Google可以简单地决定放弃对Android的Java支持，转而使用自己拥有和控制的语言，例如Go或Dart，从而离开Java。没有可靠的移动故事。 此外，选择Google的决定引起了很多人的不快。

关于JCP，JCP.next和JSPA，值得注意的是，一些较困难但最重要的项目推迟到了最后。 正如我们所看到的，这是JSPA中包含的RAND语言的解释，以及围绕它是如何绑定的周围辩论，这是Apache / Oracle分裂的核心。 商业和其他开源项目也引起了广泛的关注。 现在，Apache是​​否有权使用允许他们测试Apache许可代码的TCK尚有争议：Oracle没有向其他任何被许可方提供对TCK的这种访问，因此至少没有歧视性。 卖方可以合理地辩称，在商业方面，所有被许可方都接受使用范围限制，而在开源方面，被许可方接受仅在GPLv2下运输经过测试的产品的要求，这确保了产品将保留在开源。 Apache想要的不属于任何一个类别。 但是，无论您在该特定辩论中的立场如何，当前的JSPA中的模糊RAND语言都会引起极大的关注，尤其是以Apache问题为先例，因为它在那些希望使用TCK的人们的心中产生了疑问和不确定性。可能希望落后于该平台（无论是商业平台还是开源平台）。 如果感觉到可以以任意方式关闭TCK访问，那将避免时间和精力的投入。 明确的TCK访问和可用性信息对于JCP保持可信度至关重要。

同样地，参与者必须建立和维护自己的TCK测试环境这一事实使个人贡献者很难。 最好能看到一个社区可访问的OpenJDK测试平台，该平台将允许已签署协议并获得TCK许可证的第三方针对OpenJDK TCK测试其基于OpenJDK的代码。 理想情况下，也可以在过程中更早地提供此功能，早于实际发布（即，当规范完成且代码处于高级Beta / Release候选状态时），甚至可能在发布期间提供“草稿” TCK正在开发中。 我们确实询问了Oracle是否对此有任何计划，但没有得到答复。

但是，有谨慎谨慎的理由。 Oracle在JavaOne上进行了艰苦的工作，与Java拥护者和用户组负责人进行了交流，并且在会议上取得了显著成功。 JCP的改革非常必要，很高兴看到它们正在发生。 同样欢迎的是OpenJDK开始获得动力的迹象。 也许最令人欢迎的事实是，经过长时间的Hibernate之后，Java本身又在向前发展。

翻译自: https://www.infoq.com/articles/oracle-java-ecosystem/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

java和oracle