两个用于Eclipse的TCK –开源到底有什么？

早在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不能作为礼物：仅仅解决目前的问题还不够。如果将来会更好，我们需要进行总体更改。

参考： Eclipse的两个TCK –开源的真正含义是什么？来自我们的JCG合作伙伴 Markus Eisele在Java的企业软件开发博客中。