甲骨文严查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>Copy

4. 本地编译好，直接用 jar 包布署。

除了这个问题之外，Oracle JDK 构建过程是基于 OpenJDK 的，所以他们之间并没有技术差别。只是 OpenJDK 由于版本发布比较频繁，可能会遇到不稳定的问题。根据社区反馈，也有一些 OpenJDK 用户遇到了性能问题。而 Oracle JDK 作为商业软件，在稳定性方面要好很多。

本作品采用《CC 协议》，转载必须注明作者和本文链接