上个月，JPA 2.1专家组引发了有关用于JSR的技术兼容性套件（TCK）的可访问性的有趣辩论，该技术用于验证准确性的规范实施。 VMware的Oliver Gierke批评了当前的做法–我们与他谈了当前的情况，以及为什么他认为透明，开放的TCK流程才是答案。

贾克森特：嗨，奥利弗。 目前，JPA 2.1专家组中对TCK的可用性存在争议。 这些TCK实际上发挥了什么作用？

奥利弗·吉尔克（Oliver Gierke）：在我加入JPA专家组之前，我希望专家组在规范的基础上定义TCK，以确保它们实际上彼此一致，并且确实实现了所指定的内容。

在处理Spring Data JPA时，我反复碰到各种持久性提供程序中的问题 ，这些问题表明API的核心方法未被TCK覆盖或测试不够严格。

我询问了如何改善TCK的方法，但没有得到答案。

这就是我加紧加入专家组的原因。 加入该小组后，令我惊讶的是，加入该小组并不意味着您也可以使用TCK。 我们所能做的就是编写一封邮件，指出问题并希望以某种方式解决。

JAX：因此，TCK因此完全由Oracle控制和开发吗？

究竟。 在规范的最终版本发布之前，专家组无法访问TCK。 之后，只有被许可方才能实际访问。 至此，JSR已经结束，关于TCK的问题很难确定。 只有模糊的反馈渠道：给规格负责人的电子邮件。

JAX：也许您可以举个例子来说明当前的问题是什么？

让我们假设以下情况：我们有一个由十个团队组成的团队来定义对软件的需求。 但是该团队没有定义测试用例。 除此之外，开发团队开始根据书面规范实施代码。 他们可以与规范团队讨论问题，但不能讨论他们最终必须遵循的测试套件。 他们本质上完全是在黑暗中射击。 在这些活动的同时，第三个利益相关者实施了规范的测试用例–完全隔离，完全没有任何反馈。

现在该规范已获得批准，这意味着从那时起它已经定型。 恰好在该时间点，实现者可以访问测试用例，而他们的主要任务现在是使实现在当前TCK上运行。 在任何时候都没有实际检查TCK遵守规范中定义的程度，规范中是否有未经测试的部分等等。

如今，我们会以这种方式运行软件项目吗？ 我确信这样的项目存在于现实世界中。 我认为，这仍然不是运行软件项目的方式。 尤其是关于Java标准的开发人员将要使用多年甚至数十年的代码。

回到JSR，我们面临着另外的问题，即通常将对实现进行认证。 如果我们发现违反规范的故障导致TCK发生故障，我们该怎么办？ 取消认证实施？

没有处理TCK中问题或缺少测试的过程，也没有纠正认证的方法。 首先确定可靠的TCK至关重要的另一个原因。

因此，我们有可能（但从我实际的角度来看）也面临着规定的内容与实施者必须遵守通过TCK的要求之间的巨大空白。 尤其对于持久性提供程序之间的应用程序可移植性而言，这是一个问题，最终导致了一个问题，即是否针对模糊地指定但有效地在所有持久性提供程序中使用完全不同的语义实现的方法进行编码是否有意义。 这是从根本上破坏规范值的地方。

而且，我想提出一个问题，即如果实施者和使用API​​的开发人员的唯一权威实例与规范完全分开定义，并且现在有一种方法可以控制它们与每个规范之间的关系，那么为什么有人希望按照规范工作其他。

JAX：您描述的这些问题是否与JPA特别相关？ 或换种说法：其他专家组中是否正在进行类似的讨论？

这里的核心方面是，每个JSR都基于Java社区流程（JCP）的版本运行，该版本定义了如何运行JSR，在什么时间点需要生产什么以及拥有什么样的许可证的流程即将出版。 一些规范（例如JPA）非常接近这些规则。 但是我知道其他更开放地工作的规范（例如CDI）。 在整个规范过程中，已经获得Apache许可的CDI规范的TCK公开提供。 这避免了规范和TCK之间的差距，并同时整合了社区。 当然，这并不意味着可以完全避免规格中的歧义，但可能性很小。

JAX：您对改善当前状况有何建议？

我要拍摄两件事。 首先，规范和TCK应该彼此并存，例如，我们可以坚持不提供专用测试用例就不能指定API。 当然，这需要专家组成员访问TCK。 实现者将从中特别受益，因为他们无需执行超过两年的时间就可以对他们的代码进行测试。
我热烈欢迎的第二件事是如何处理TCK故障。 必须有一种持续改进测试套件的方法。

JAX：您是否希望看到TCK完全开源并免费提供给社区？

究竟。 已经提到的CDI规范表明这是可能的。 TCK在GitHub上可用 -每个人都可以使用“ forkable”和“ improveable”。 为什么这不适用于其他JSR？

JAX：Oracle的Linda DeMichiel最近在邮件列表中写道，Oracle没有专门的JPA TCK团队。 她提到其他JSR的TCK已提前完成。 其他专家组的服务时间更早了吗？ 听起来好像Oracle的TCK团队并不大，所以准备工作只需要很多时间。

这是非常好的一点。 很难找到有关谁正在为JPA 2.1开发TCK的细节。 琳达还提到，到目前为止，还没有人真正对帮助TCK表现出兴趣。 重要的是要注意，我不想指责某人做不好的事情。

我的主要观点是，我认为当前流程存在缺陷，并且会对标准质量产生负面影响。 我知道更好的TCK首先意味着要做更多的工作，我当然愿意提供帮助。 也许我们甚至可以通过Adopt-a-JSR计划找到更多的志愿者。 但是我确实认为，如果流程不开放，实际上是不可能帮助的，那么很难吸引人们。 除此之外，我认为大多数使用像JPA这样的标准的开发人员都没有意识到差距以及为什么当前状态实际上是有问题的。

如果您现实地看待这种情况，您是否认为当前情况会很快改变？ Oracle准备好进行建设性的对话了吗？

我已经提到过，即使作为JPA专家组的成员，获取信息也不容易。 另一方面，我看到它适用于其他规范。 在这方面，我认为这次讨论是创造透明度并希望同时引起人们对社区参与的兴趣的机会。 最终，它是关于一个设计良好且可用的API。 有太多的API可供开发人员狂奔。 因此，每一项微小的改进都是重要的。

因此，您想扩大对此问题的讨论-我们的读者可以在这里发表评论并分享他们的观点。 他们还可以做些什么来参与讨论？

首选方式当然是用户的邮件列表 。 除此之外，我们还维护一个JIRA实例，以收集针对专用工作块的反馈。