爭論：JCP在Java的未來中將扮演什麼角色？[轉]

作者 Ryan Slobojan 譯者 王軍

最近，Alex Blewitt 稱Java Community Process（JCP）已經死了，將之喻為無頭雞：“自己還沒有意識到，仍在四處奔跑，但實際已死了”。由此引發一場關於JCP作用，及其在Java的未來中將扮演什麼角色的爭論。

Alex Blewitt在博文中指出了關於Java和JCP的幾個利害關係：

• JCP導致了更大的JVM，幾乎沒有移除什麼，反倒是加入了不少東西
• 現在，VM要求所有東西都要出現，沒有什麼東西可以被移除——Consumer JRE是一個好的開端，但它只是將jar的下載延遲到需要的時候，而不是一開始就把它們全部下載——整個JRE仍然需要下載
• Java需要一個新的模組系統允許動態的、按需的元件下載，這樣不用下載那些從不使用的內容
• 儘管一些模組系統在現今Java上存在併發揮作用，但是一些正在為Java 7建立的新內容可能比現有解決辦法更加臃腫且功能更少，而且可能會被大多數實現者（類似java.util.logging和XML解析器）所取代
• 對Java的演變管理工作幾乎沒什麼幫助（無論是減少還是增加）
• 微軟正在語言前線打擊Java —— .Net有好些正被大量開發者日常使用的語言，Java實際上只有Java語言，其它的還是“小魚苗”——Java在一些語言特性（如範型、延續（continuation）和函式即數值（functions as values））上還正在扮演追隨者。
• 儘管對於象Scala這樣的跨VM（cross-VM）語言有一些適當的機遇，但是最有可能的未來之路是Google的GWT和Android的方式——複用Java語言，但瞄準Java API的一個子集，並發展JCP之外的產品以避免不這樣而招致的額外包袱
• J2ME是個災難 —— 有大量碎片在裝置中，並且J2ME無法處理像藍芽、USB或撥號器這樣有用的東西
• JSRs是個重負，只是使一個已經臃腫的平臺更加臃腫——JCP阻礙了輕量級、模組化方式和在此之外的真正創新

Blewitt還指出:

JCP不關乎於社群，它關乎於控制。通讀任一JSRs，有一節是“為什麼不用現有系統來解決”。通讀它們是一個市場營銷的練習；這兒總是沒有真正的理由，而只是說‘我們可以做的更好/不同的/較小的/更快的’。在這種情況下實際發生的是，該規範領導們沒有絲毫興趣在現有基礎上進行構建；他們想要得到他們自己版本的程式碼庫（不論是真的或被提議的），並且這些論點基本上是‘因為我們沒有寫它’。那些所謂的‘專家小組’只不過是對開發者（通常就是JSR的提交者）進行同行評審，並對實際上已經開發程式碼的影響為零。（一般情況下，JSR的提交者將只給程式碼開發者提供資助，而不是尋求專家小組的幫助，這樣他們能擁有過程的所有智慧財產權）。換句話說，你想做的任何事都要得到他們的支援同意

其他人評論說：Google應該領導Java的發展, 或Java將會很快被一個真正的並行語言取而代之. 然而一些人擔心模組化會引起這個平臺的分裂。

就在上帖釋出的同一天，的聯合帶頭人Jean-Marie Dautelle為JCP徵求

• 公開辯論，開放郵件列表並公開會議
• C字母在JCP中代表著社群，而該委員會與公司利益似乎更重於社群利益
• 更多個人和小公司的參與，更多開放原始碼的相容性（如減少NDAs和私有元件），以及JRS專家組成員能更公開接近並接受公眾意見
• (Hans Muller領導的) 是JSR正確做事的一個很好例子，並建議JSR始終容納一個領域專家，開放原始碼解決方案始終得到認真的考慮，並要求所有JSRs在公開化和社群參與性方面按照296的領導
• 來自個人和小團體的輸入與公司的輸入一樣重要，並且JCP應承認如Spring和Apache Commons這樣事實上的標準

Dautelle的問題也引起了（日期和時間API）聯合帶頭人的。Colebourne問道:

這個問題引出了更廣泛的Java監管問題。Java現在是開源的，但我們現在還沒有真正清楚這是如何運作或影響JCP的。

特別是，誰是監查Java發展和其未來方向的‘建築師’？是Sun公司中某人？一個隱藏的神奇過程？或命中和希望嗎？

Colebourne想知道誰決定了哪些語言變化加入到Java 7，核心庫的變化是如何發生的，以及為什麼JSR 277模組管理系統要像這樣處理 —— 他還提出了幾個問題：

1. Sun（例如：Apache Harmony）。這摧毀了全部的信任。
2. JCP依然存在於照章批准大公司成員提出的建議。基本上，一個公司提交他們已有的程式碼，‘專家組’實際上存在於對之做同行評審。
3. JCP或Sun在Java的方向上都沒有任何感覺。 在對Java走向何方以及它最終成為什麼的問題上應該有明確認識 —— 一個五到十年的遠景。
4. JCP並不消除重複的JSRs （看看OSGi）。更糟的是，它讓更壞的選擇得以成功。
5. 個人擁有太小的發言權。他們試圖透過提供創新和破壞來讓大公司保持正直。

Colebourne也提出了幾種解決方案，例如一個將公佈Java五到十年遠景的架構組，一個規模更大、更自主的JCP執行委員會，給JSR成員付工資，以及一個針對Apache Harmony正確的TCK技術相容包。提出的另一種選擇就是淘汰JCP，並將Java重新定義為建立在一個核心之上基於OSGi的模組化VM —— 廠商可以隨意混合匹配，市場將決定誰是贏家。Patrick Wright這些觀點，他指出在Apache-Sun Harmony的爭論中，只有Apache公佈了他們的一面之辭。Wright還質疑一個五到十年的遠景到底能對語言發展的高速步伐提供多大的價值。

也在辯論中進行了權衡，關於分析，他同意Colebourne，但。Kriens還提出了一個新的問題——什麼更切合實際，是實現還是規範？Kriens指出規範允許瞄準不同需求的多種實現，透過平衡眾多組織的需求，它保持了中立。緩慢的標準化程式允許實時地思考解決辦法，並且智慧財產權的問題往往較容易處理。回應道JCP和OSGi都太被大公司控制了，而且規範被私有元件所拖累——儘管他們都值得擁有。 Kriens回應道，大公司的支援對規範的成功是重要的，並且儘管Sun對JCP有不成比例數量的控制權，但OSGi的所有成員均一視同仁。

你有什麼想法呢？

檢視英文原文：