Categories
程式開發

Java小想法: JDK許可證


是的,Java已經25周歲了。 25週年,我們可以聊聊Java世界的一些見聞和小想法。首先我想到的,就是JDK許可證的變化,以及隨之而來的困惑、誤解,以及變化帶來的生態效應。

這兩年,影響Java生態格局最大的事情,莫過於起始於2018年的JDK許可模式和發布模式的變更。

老的許可證什麼樣?

十多年來,Java SE的授權一直使用BCL模式。 BCL模式允許用戶在一定的限制條件下,免費使用JDK。比如,下面就是一個免費許可及其限制的條款:

2. LICENSE TO USE. Subject to the terms and conditions of this Agreement including, but not limited to, the Java Technology Restrictions of the Supplemental License Terms, Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs. THE LICENSE SET FORTH IN THIS SECTION 2 DOES NOT EXTEND TO THE COMMERCIAL FEATURES. YOUR RIGHTS AND OBLIGATIONS RELATED TO THE COMMERCIAL FEATURES ARE AS SET FORTH IN THE SUPPLEMENTAL TERMS ALONG WITH ADDITIONAL LICENSES FOR DEVELOPERS AND PUBLISHERS.

由於大部分實際用戶都能夠滿足這些限制條件,JDK一直被認為是一個免費的軟件。事實上,BCL是一個兼具免費和付費的許可證。長期以來,付費的用戶為Java SE的發展提供了必要的資金支持。

新的許可證什麼樣?

從JDK 11發布開始,也就是2018年9月份,Oracle開始發布兩個不同許可證的JDK:開放版(GPLv2+CPE)和商業版。

開放版的JDK叫做OpenJDK,可以從jdk.java.net“網站下載。商業版的JDK叫做OracleJDK,可以從Oracle.com“網站訂閱、下載和使用,也可以通過你的Oracle產品支持渠道獲得。

BCL這種混合了免費和商用的許可證,除了容易引起混淆之外,還會給用戶造成不必要的麻煩。比如有的用戶只允許使用商業許可證,有的用戶只允許使用開放許可證。免費和商用混合的許可證,給用戶的許可證管理帶來了一定的麻煩。發布兩個不同的許可證,就沒有這些麻煩事了。

而且,GPLv2許可證是比BCL的免費部分更加開放的許可;商業許可證是比BCL的商業部分更加明確、商業支持更到位的許可。

免費用戶和付費用戶本來就是兩類不同的用戶。現在,免費的用戶可以獲得更開放的許可,付費的用戶可以獲得更商業的支持。這是許可模式的簡化。

OracleJDK有什麼不一樣?

和OpenJDK相比,OracleJDK有什麼不同呢?

由於歷史的原因,當Java SE開源的時候,有一些代碼當時存在許可證的問題,沒有辦法開放源代碼。比如ZGC和JFR。這幾年,Oracle已經陸續地解決了這些許可證的問題,並且開放了這部分源代碼。從JDK 11開始,OpenJDK和OracleJDK本質上沒有什麼區別。

既然是一樣的,為什麼還要使用兩個許可證呢?都GPLv2不就簡單了嗎?有這個問題的用戶,一定不理解商業許可的需求,和付費用戶的訴求。

爭議從何而來?

看似兩個許可證模式對應不用的用戶群體,各有所好,各取所需,為什麼JDK許可模式的變更引起了這麼多爭議?過了一年多,再看看這個變更,為什麼引起了Java生態格局這麼大的變化?

除了許可證變更之外,我們還有關注隨之而來的另外一個變更。這就是Oralce發布模式的變更。許可證本身沒有什麼問題,只是簡化了用戶的選擇。但是發布模式的變更,給Java生態格局帶來了巨大的變化。

記得十多年前,有一位Java One參會者提問,JDK發布太快了,他們跟不上,版本更新能不能再慢點?這個問題固然代表了一種觀點。我對這個問題印象深刻,主要是因為我追出去老遠解釋大半天,這位拂袖憤懣的Java用戶依然難掩對版本更迭過快的不滿。

JDK發布有多快呢? Java SE 9之前,一般是兩年或者三年一個版本。從Java SE 9開始,Oracle調整了版本發布策略,半年發布一個小版本,三年發布一個大版本(Long-Term-Support (LTS) release)。對於Java SE的設計和研發,這種發布節奏簡直就是翻天覆地的變化。研發計劃、資源配置、研發流程等都要跟著這種節奏調整。

Java SE 9之前,Java SE研發團隊還有少許的時間照看JDK的更新版。半年一個版本的節奏,使得研發團隊的不得不把主要精力放在關鍵問題的修復,和未來特性的擴展上。也就是說,Java SE研發團隊的主要任務要朝前看。

那麼,更新版怎麼辦?一個大版本要維護至少6年,沒有更新版是一件不可想像的事情。幸運的是,到2018年,Java SE開放源代碼已經十一二年了。 Java社區已經積累了足夠的力量。

2018年,這股力量有意願,也有能力承接JDK的更新版了。

JDK是開源的,Oracle的每一個更新,都會體現在OpenJDK裡。 JDK社區只要評估這些更新,並且整合到以前的版本里,就可以獲得相應的更新版了。

Oracle放手後,Redhat領導了OpenJDK更新版的維護。而OracleJDK的更新只面向付費用戶。商業用戶的通過鈔票的投票,來選擇和支持Oracle的JDK維護團隊。

Java SE團隊照看好未來,OpenJDK社區照看好現在,OracleJDK支持好商業用戶。這看起來是一個相當不做的模式。

有哪些生態的變化?

發布模式的變更,雖然有很多爭議,但實質上帶來了非常積極的變化,而且大都是好的變化。

Java社區活躍了

我能看到的第一個變化,是Java社區終於活躍起來了。

到2018年九月份,Java SE開源11年還要多了。我們看到的活躍在Java社區的開發者,大部分都是Oracle的研發人員,很少看到其他的貢獻者。

其實,這個原因很簡單。 Java SE團隊的成員似乎能解決一切問題,滿足所有的迫切需求。社區裡有問題,有需求,只要提問題就好了。大部分時候,總會有Java SE團隊的成員站出來解決掉。 Java社區的其他開發者,沒有動手解決掉問題的迫切需求和動力。

2018年到現在的一年半時間,我可以明確感受到Java社區的沸騰程度。這股積攢了十多年的研發力量,終於爆發了出來。這些力量來自於Redhat,來自於SAP,來自於阿里巴巴,來自於騰訊,來自於很多知名的、不知名的,團隊的、個人的各種各樣的開發者。這些開發者評估新版本的變更,貢獻代碼更新,協作評審、測試、調試代碼變更。似乎一夜之間,Java社區的力量就被啟動了。

比如說吧,之前的OpenJDK的郵件列表,我們每天只能看到很少的郵件。而且這些郵件大都來自於Oracle的Java研發團隊。現在,單單是JDK 8更新這一個郵件列表,每天都有幾十封郵件,而且大部分郵件都來自於Oracle以外的開發者。很多問題的討論,都有不同背景、不同地域、不同公司的開發者參與討論。這在一年多以前,是不可想像的事情。

Java創新速度加快

Java SE團隊照看好未來,這樣的選擇讓Java SE團隊的專家能夠更有效地分配好、使用好他們的時間。這樣,就能夠讓每一個小版本都有新意,每一個小版本都有提升。如果你認真研究下JDK 11以來發布的小版本,對比一下JDK 11之前的版本特性,你應該也可以感受到這種速度和質量的變化。

JDK專家隊伍擴大

只靠閱讀JDK的代碼,是成不了JDK專家的。要成為專家,是需要把自己放進來,親自動手貢獻代碼的。

我自己有一些印像比較深刻的人和事。

有一個剛畢業不久的小伙子,兩三年以前,還只能問問簡單的問題。後來,試著修復一些小問題。當時的代碼,實在是讀不下去的。提交上來的更新,幾乎都要推倒了重新整理思路,每一行代碼似乎都可以改一改。

也就是這兩年,由於OpenJDK版本維護的需要,他做了大量的更新評估和維護。現在,他可以處理非常複雜的問題,領導複雜的更新和維護,已經是OpenJDK裡的活躍用戶和高質量的貢獻者。這種成長的速度,是讓人有點吃驚的。

OpenJDK版本維護,需要自己動手。而自己動手,能夠讓更多的開發者參與進來,成長為相關領域的專家。

更健壯的OpenJDK

很多人擔心,沒有了Java SE團隊的照看,OpenJDK版本的質量會不會發生變形?這種擔心是有道理的,也是應該的。可是,一件事往往是多種因素相互影響的結果。

經過一年多時間,當我回頭看OpenJDK版本的質量時,我不僅沒有了這種擔心,還看到了更多的推動質量改進的因素。

但OpenJDK的版本不再控制在一家公司手裡的時候,多種聲音、多種需求就出現了。這些聲音和需求,會推動著OpenJDK版本的持續地改進。

比如說,JFR是JDK 11的一個強大的功能。這個新功能雖然有很多的現實需求,但是由於涉及到大量的代碼,一般情況下,是不會考慮整合到以前的更新版本里的。由於很多企業還在大量使用JDK 8,這就有了把JFR整合到JDK 8裡的渴望。包括阿里巴巴在內的很多開發者,一起推動了JFR在JDK 8的整合工作。這實在是一個社區推動軟件更新的一個典範。

個性化的JDK版本

JDK的缺省實現和設置,是一個多方平衡、調適的結果,大體只能做到兼顧大部分場景。可是有很多體量巨大的用戶,他們有著特殊的需求,需要把JDK調整到最適合他們的生產力場景。

比如說,阿里巴巴就對JDK的性能有個苛刻的要求。這就需要深挖JDK的潛力,把JDK調適到最好的性能,最適合阿里巴巴的運行場景。於是,我們看到了阿里巴巴自己發布的Dragonwell,騰訊發布的Kona。這些基於OpenJDK的發布版,滿足了不同客戶的個性化需求。

自然地,這些個性化需求,也會催生很多創新,並且回饋給OpenJDK。這是一個多贏的局面。

最後,希望我們有這樣的共識:

Java SE許可證的變化簡化了用戶的選擇,沒什麼大不了的事情。 Java SE發布模式的變更,像一個蝴蝶扇動了翅膀,Java生態格局有了積極的變化。 OpenJDK社區的能力正在爆發,他們會是推動Java前進的一股不可或缺的力量。

好的,今天我們就聊到這兒。