早在5月，Oracle就向Eclipse Foundation 授予了兼容性测试奖学金 。 在过去的几天里，这引起了媒体的关注，我只是想确保我对整个过程和详细动作有所了解。 看起来像是一见钟情的简单诚实的礼物实际上具有更多的方面。 但让我们从头开始：

技术兼容性套件

由Java社区流程（JCP）覆盖，开发了Java语言和最上层的各种平台（Java SE，Java EE，Java ME）。 每个JSR（Java规范请求）包括EG（专家组）一堆文件，当然还有参考实现（RI）和相应的TCK（技术兼容性套件）。 可以对照实现执行TCK，并检查它们是否符合规范。 因此，它基本上是规范文档的代码等效项。 大多数TCK包含一堆测试用例以及执行测试的“测试工具”。 如果每个JSR有一个TCK，可以安全地假定至少有与我们在JCP中拥有活动JSR一样多的TCK。 但这只是理论上的想法。 实际上没有。 至少没有公开可用。 除了JBatch，CDI和Bean验证之外，我想不得多了。 这些只是Java EE平台的一部分，该平台至少具有28个规范。 不幸的是，大多数TCK都在Oracle的控制之下。 但为什么？ 这样做的主要原因是，TCK还用作平台认证的工具。 针对实现成功运行TCK证明了它的正确性以及某种程度上的合规性。

平台认证实际上是什么意思？

平台兼容性是产品的绝佳广告。 Java EE兼容性列表是Java EE服务器市场的“谁是谁”。 如果您的产品不在该列表中，则基本上没有机会被认可。 Apache Tomcat是该规则的唯一已知例外。 但是，获得认证需要什么呢？ 对于Java EE，有一个Java EE兼容性测试套件（CTS），可能只包含各个TCK的总和。 老实说我没看过。 您必须成为Oracle的被许可方才能访问它。 而这正是它开始变得昂贵的地方。 我不知道到底有多贵，但是一旦付款，您就可以通过Java Partner Engineering网站访问CTS。 只有一种方法可以使用CTS。 通过兼容性测试奖学金计划 ，这是非营利组织和个人申请免费CTS的一种方式。 这些请求由审查委员会进行判断。 那里有一个PDF ，解释了此过程的工作原理。 截止到今天，除ASF之外，其他各种组织和个人也可以使用个人TCK和CTS。 现在，您已经了解了基本程序和认证，现在可以更轻松地查看已获得CTS奖学金的两个Eclipse项目的详细信息。 我需要在下面加上一些免责声明。 我只能从众所周知的结论中得出结论。 对于背后的原因，我没有任何见解或进一步的信息。 它可能比我想出的要简单得多……

EclipseLink – JPA参考实现

根据5月初的新闻稿，Oracle通过向Eclipse Foundation授予对两个TCK的访问权限和相关的支持服务来展示其“对Java开发人员和开放源代码社区的承诺”。 是时候开始思考了。 EclipseLink不是JPA的RI吗？ 如果不自己为JPA构建TCK，他们到底在做什么？ 他们为什么需要许可证？

EclipseLink的根源于TopLink。 任何了解TopLink历史的人都知道，这是一个相对较旧的产品，在被Oracle收购之前，它属于WebGain。 WebGain曾是Eclipse的强大支持者，甚至在2002年还是董事会成员。仅在Oracle TopLink收购WebGain五年后，WebGain便被捐赠给Eclipse Foundation。
从此 。 EclipseLink在EPL 1.0下可用。 项目本身不包含TCK。 RI的困境。 查看提交者列表并不十分令人兴奋。 30个人 而且只有一个非Oracle。 我为什么认为这个团队实际上拥有TCK（内部是Oracle）甚至开发它？ 严格来说，EclipseLink的许可不符合TCK许可规则。 此处授予奖学金许可证只是纠正了该星座中的一些法律问题。

处女座– Java EE Web Profile Server

但是对于处女座，授予的许可确实会有所作为，对吧？ 也许。 处女座是以前的Spring dm服务器，由SpringSource在2010年捐赠给Eclipse Foundation。 提交者列表绘制的图片与TopLink列表不同。 每个名字背后都不仅仅是SAP。 提交者在三家公司之间平均分配。 SAP，Pivotal和Tasktop技术。 后者有一个有趣的管理委员会。 SpringSource前首席运营官Neelan Choksi和Rod Johnson本人也是成员。 这可能表明Pivotal对项目的影响要比SAP多。 无论如何，两家公司很可能不是甲骨文的大伙伴。 奖学金许可证显然不是送给他们的礼物。 实际上，处女座已经通过Java EE 6认证。 但是，用另一个名字。 SAP NetWeaver Cloud在处女座上建立了Java EE 6 Web Profile产品。 因此，SAP可能已经从Oracle获得了许可证，并自己获得了Virgo的认证。 我不确定，但有人可能会想到，使用已经认证的服务器比逐年支付年度专利费便宜。 鉴于Eclipse基金会是一个非营利组织，因此很容易申请奖学金计划来进行排序。 至少在这种情况下有积极的副作用。 处女座现在有机会成为另一个获得Java EE认证的服务器。 SAP已经证明了这是可能的。 不久以后，社区可能会通过拥有新的EE 7认证的OSS服务器来获利。

但这是线下的正数，对吗？

两个新项目可以访问他们正在实施的规范的TCK。 那是积极的。 从公开可用的TCK总数来看，仍然令人沮丧。 尤其是在EclipseLink的情况下，这令人沮丧，因为TCK可能根本不公开。 去年对JPA邮件列表进行的冗长讨论稍微讨论了此问题并说明了缺点。 尽管随着JSR-348的更改而变得越来越好。 我们还不在那里。 实际上，我希望所有相关方都可以使用TCK。 通过在规范中以及在RI的测试区域不足的地方发现漏洞，可以提高规范和参考实现的质量。 两者都可以防止许多错误影响用户。 作为针对TCK的新许可模型的工作，是JSR 358的关键部分。 随附的Java.net项目包含所有讨论资料，并且可以公开访问。 每个人都可以自由参加讨论并发表自己的意见。 观察者邮件列表可用于任何已注册的java.net用户。 如果您对CloudBees，Red Hat和IBM对许可问题的看法感兴趣，可以在演示页面上找到更多资料。 Oracle本身建议在JCP的未来版本中继续使用标准的TCK许可模型：

“必须根据一项或多项已批准的开源许可证和/或标准商业TCK许可证，为将来的所有JSR提供TCK，以用于认证和商标目的。 必须根据标准的JCP社区TCK许可证，将所有未来非伞式JSR的TCK提供给相关RI开源项目的所有参与者。 ”（来源： Oracle针对JSR 358的提案 ，PDF，第15 +16页）

这将是朝着正确方向迈出的一步，并且将对开源社区产生真正的帮助。 如果授予的TCK不能作为礼物：仅仅解决目前的问题还不够。 如果将来会更好，我们需要进行总体更改。

翻译自: https://www.javacodegeeks.com/2013/08/two-tcks-for-eclipse-what-is-really-in-it-for-open-source.html