早在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的企業軟件開發博客中。

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

總結

以上是生活随笔為你收集整理的两个用于Eclipse的TCK –开源到底有什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。