早在5月，Oracle就向Eclipse Foundation 授予了兼容性測試獎學金 。 在過去的幾天里，這引起了媒體的關注，我只是想確保我對整個過程和詳細動作有所了解。 看起來像是一見鐘情的簡單誠實的禮物實際上具有更多的方面。 但讓我們從頭開始：

技術兼容性套件

由Java社區(qū)流程（JCP）覆蓋，開發(fā)了Java語言和最上層的各種平臺（Java SE，Java EE，Java ME）。 每個JSR（Java規(guī)范請求）包括EG（專家組）一堆文件，當然還有參考實現(xiàn)（RI）和相應的TCK（技術兼容性套件）。 可以對照實現(xiàn)執(zhí)行TCK，并檢查它們是否符合規(guī)范。 因此，它基本上是規(guī)范文檔的代碼等效項。 大多數(shù)TCK包含一堆測試用例以及執(zhí)行測試的“測試工具”。 如果每個JSR有一個TCK，可以安全地假定至少有與我們在JCP中擁有活動JSR一樣多的TCK。 但這只是理論上的想法。 實際上沒有。 至少沒有公開可用。 除了JBatch，CDI和Bean驗證之外，我想不得多了。 這些只是Java EE平臺的一部分，該平臺至少具有28個規(guī)范。 不幸的是，大多數(shù)TCK都在Oracle的控制之下。 但為什么？ 這樣做的主要原因是，TCK還用作平臺認證的工具。 針對實現(xiàn)成功運行TCK證明了它的正確性以及某種程度上的合規(guī)性。

平臺認證實際上是什么意思？

平臺兼容性是產(chǎn)品的絕佳廣告。 Java EE兼容性列表是Java EE服務器市場的“誰是誰”。 如果您的產(chǎn)品不在該列表中，則基本上沒有機會被認可。 Apache Tomcat是該規(guī)則的唯一已知例外。 但是，獲得認證需要什么呢？ 對于Java EE，有一個Java EE兼容性測試套件（CTS），可能只包含各個TCK的總和。 老實說我沒看過。 您必須成為Oracle的被許可方才能訪問它。 而這正是它開始變得昂貴的地方。 我不知道到底有多貴，但是一旦付款，您就可以通過Java Partner Engineering網(wǎng)站訪問CTS。 只有一種方法可以使用CTS。 通過兼容性測試獎學金計劃 ，這是非營利組織和個人申請免費CTS的一種方式。 這些請求由審查委員會進行判斷。 那里有一個PDF ，解釋了此過程的工作原理。 截止到今天，除ASF之外，其他各種組織和個人也可以使用個人TCK和CTS。 現(xiàn)在，您已經(jīng)了解了基本程序和認證，現(xiàn)在可以更輕松地查看已獲得CTS獎學金的兩個Eclipse項目的詳細信息。 我需要在下面加上一些免責聲明。 我只能從眾所周知的結(jié)論中得出結(jié)論。 對于背后的原因，我沒有任何見解或進一步的信息。 它可能比我想出的要簡單得多……

EclipseLink – JPA參考實現(xiàn)

根據(jù)5月初的新聞稿，Oracle通過向Eclipse Foundation授予對兩個TCK的訪問權(quán)限和相關的支持服務來展示其“對Java開發(fā)人員和開放源代碼社區(qū)的承諾”。 是時候開始思考了。 EclipseLink不是JPA的RI嗎？ 如果不自己為JPA構(gòu)建TCK，他們到底在做什么？ 他們?yōu)槭裁葱枰S可證？

EclipseLink的根源于TopLink。 任何了解TopLink歷史的人都知道，這是一個相對較舊的產(chǎn)品，在被Oracle收購之前，它屬于WebGain。 WebGain曾是Eclipse的強大支持者，甚至在2002年還是董事會成員。僅在Oracle TopLink收購WebGain五年后，WebGain便被捐贈給Eclipse Foundation。
從此 。 EclipseLink在EPL 1.0下可用。 項目本身不包含TCK。 RI的困境。 查看提交者列表并不十分令人興奮。 30個人 而且只有一個非Oracle。 我為什么認為這個團隊實際上擁有TCK（內(nèi)部是Oracle）甚至開發(fā)它？ 嚴格來說，EclipseLink的許可不符合TCK許可規(guī)則。 此處授予獎學金許可證只是糾正了該星座中的一些法律問題。

處女座– Java EE Web Profile Server

但是對于處女座，授予的許可確實會有所作為，對吧？ 也許。 處女座是以前的Spring dm服務器，由SpringSource在2010年捐贈給Eclipse Foundation。 提交者列表繪制的圖片與TopLink列表不同。 每個名字背后都不僅僅是SAP。 提交者在三家公司之間平均分配。 SAP，Pivotal和Tasktop技術。 后者有一個有趣的管理委員會。 SpringSource前首席運營官Neelan Choksi和Rod Johnson本人也是成員。 這可能表明Pivotal對項目的影響要比SAP多。 無論如何，兩家公司很可能不是甲骨文的大伙伴。 獎學金許可證顯然不是送給他們的禮物。 實際上，處女座已經(jīng)通過Java EE 6認證。 但是，用另一個名字。 SAP NetWeaver Cloud在處女座上建立了Java EE 6 Web Profile產(chǎn)品。 因此，SAP可能已經(jīng)從Oracle獲得了許可證，并自己獲得了Virgo的認證。 我不確定，但有人可能會想到，使用已經(jīng)認證的服務器比逐年支付年度專利費便宜。 鑒于Eclipse基金會是一個非營利組織，因此很容易申請獎學金計劃來進行排序。 至少在這種情況下有積極的副作用。 處女座現(xiàn)在有機會成為另一個獲得Java EE認證的服務器。 SAP已經(jīng)證明了這是可能的。 不久以后，社區(qū)可能會通過擁有新的EE 7認證的OSS服務器來獲利。

但這是線下的正數(shù)，對嗎？

兩個新項目可以訪問他們正在實施的規(guī)范的TCK。 那是積極的。 從公開可用的TCK總數(shù)來看，仍然令人沮喪。 尤其是在EclipseLink的情況下，這令人沮喪，因為TCK可能根本不公開。 去年對JPA郵件列表進行的冗長討論稍微討論了此問題并說明了缺點。 盡管隨著JSR-348的更改而變得越來越好。 我們還不在那里。 實際上，我希望所有相關方都可以使用TCK。 通過在規(guī)范中以及在RI的測試區(qū)域不足的地方發(fā)現(xiàn)漏洞，可以提高規(guī)范和參考實現(xiàn)的質(zhì)量。 兩者都可以防止許多錯誤影響用戶。 作為針對TCK的新許可模型的工作，是JSR 358的關鍵部分。 隨附的Java.net項目包含所有討論資料，并且可以公開訪問。 每個人都可以自由參加討論并發(fā)表自己的意見。 觀察者郵件列表可用于任何已注冊的java.net用戶。 如果您對CloudBees，Red Hat和IBM對許可問題的看法感興趣，可以在演示頁面上找到更多資料。 Oracle本身建議在JCP的未來版本中繼續(xù)使用標準的TCK許可模型：

“必須根據(jù)一項或多項已批準的開源許可證和/或標準商業(yè)TCK許可證，為將來的所有JSR提供TCK，以用于認證和商標目的。 必須根據(jù)標準的JCP社區(qū)TCK許可證，將所有未來非傘式JSR的TCK提供給相關RI開源項目的所有參與者。 ”（來源： Oracle針對JSR 358的提案 ，PDF，第15 +16頁）

這將是朝著正確方向邁出的一步，并且將對開源社區(qū)產(chǎn)生真正的幫助。 如果授予的TCK不能作為禮物：僅僅解決目前的問題還不夠。 如果將來會更好，我們需要進行總體更改。

參考： Eclipse的兩個TCK –開源的真正含義是什么？ 來自我們的JCG合作伙伴 Markus Eisele在Java的企業(yè)軟件開發(fā)博客中。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。