甲骨文嚴查Java授權 、 openJDK 注意避坑

背景

外媒The Register報導，甲骨文稽查企業使用者，近期開始將把過去看管較鬆散的Java授權加入。

甲骨文針對標準版Java（Java SE）有2種商業授權。2019年4月甲骨文宣佈Java SE使用者需要付費訂閱，才能取得授權及更新，包括Java SE 7、8或11、12。但到同年9月該公司又宣佈了免費Java授權方案，針對Java 17版本提供每季更新，並在2021年的新版本提供多1年免費支援，但這項方案並不溯及既往，舊版Java使用者即使安裝修補程式也是需要付費。

報導指出，最近一些美國企業收到甲骨文授權管理部門的訊息，詢問Java授權數量。此外甲骨文也從資料庫、中介軟體或應用授權，來推敲使用者的Java授權是否為虛報。例如，資料庫的數量可以反映 CPU 數量，Java SE 訂閱價格的其中一個收費標準為每個 CPU 每月收費 25 美元，因此就可以反映出 Java SE 訂閱數量是否符合要求。

在這個背景下一些企業已開始用 OpenJDK 開源替代方案應對甲骨文的審計。但是OpenJDK與甲骨文標準版之間存在差異。今天我們們就來聊聊這些差異。

JDK和OpenJDK的區別

關於JDK和OpenJDK的區別，可以歸納為以下幾點：

授權協議的不同

OpenJDK採用GPL V2協議，而JDK則採用JRL。兩者協議雖然都是開放原始碼的，但是在使用上的不同在於GPL V2允許在商業上使用，而JRL只允許個人研究使用。

OpenJDK不包含Deployment（部署）功能

部署的功能包括：Browser Plugin、Java Web Start、以及Java控制皮膚，這些功能在Openjdk中是找不到的。

OpenJDK原始碼不完整

這個很容易想到，在採用GPL協議的Openjdk中，sun jdk的一部分原始碼因為產權的問題無法開放openjdk使用，其中最主要的部分就是JMX中的可選元件SNMP部分的程式碼。因此這些不能開放的原始碼將它製作成外掛，以供OpenJDK編譯時使用，你也可以選擇不要使用plug。而Icedtea則為這些不完整的部分開發了相同功能的原始碼(OpenJDK6)，促使OpenJDK更加完整。

部分原始碼用開原始碼替換

由於產權的問題，很多產權不是SUN的原始碼被替換成一些功能相同的開原始碼，比如說字型柵格化引擎，使用Free Type代替。

OpenJDK只包含最精簡的JDK

OpenJDK不包含其他的軟體包，比如Rhino Java DB JAXP……，並且可以分離的軟體包也都是儘量的分離，但是這大多數都是自由軟體，你可以自己下載加入。

不能使用Java商標

這個很容易理解，在安裝openjdk的機器上，輸入“java -version”顯示的是openjdk，但是如果是使用Icedtea補丁的openjdk，顯示的是java。（未驗證）

OpenJDK之坑

一個在 Java SE 中穩定執行了一年多的專案，最近在OpenJDK上部署測試。一個案例失敗。原因是缺少javafx.util。

這裡的javafx.util包在jdk 1.8的類庫裡面有，但在OpenJDK 8裡面是沒有的。解決方式也很簡單，主要如下幾種做法：

1. 不要使用javafx.util這種OpenJDK裡面沒有的包；

2. 下載javafx-sdk到伺服器，編譯時將javafx-sdk位置作為--module-path引數傳入；

3. 在pom裡面顯式新增javafx依賴，這樣在伺服器上用mvn編譯時，會把它從maven中央倉庫拉到本地打包到你的工程裡。

<!-- java專案 fhadmin.cn--><dependency>
    <groupId>org.openjfx</groupId>
    <artifactId>javafx-base</artifactId>
    <version>14-ea+7</version></dependency>

4. 本地編譯好，直接用jar包佈署。

除了這個問題之外，Oracle JDK構建過程是基於OpenJDK的，所以他們之間並沒有技術差別。只是OpenJDK由於版本釋出比較頻繁，可能會遇到不穩定的問題。根據社群反饋，也有一些OpenJDK使用者遇到了效能問題。而Oracle JDK作為商業軟體，在穩定性方面要好很多。