甲骨文严查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里面是没有的。解决方式也很简单，主要如下几种做法：
-
不要使用javafx.util这种OpenJDK里面没有的包；
-
下载javafx-sdk到服务器，编译时将javafx-sdk位置作为--module-path参数传入；
-
在pom里面显式添加javafx依赖，这样在服务器上用mvn编译时，会把它从maven中央仓库拉到本地打包到你的工程里。
<dependency> <groupId>org.openjfx</groupId> <artifactId>javafx-base</artifactId> <version>14-ea+7</version> </dependency>4. 本地编译好，直接用jar包布署。
除了这个问题之外，Oracle JDK构建过程是基于OpenJDK的，所以他们之间并没有技术差别。只是OpenJDK由于版本发布比较频繁，可能会遇到不稳定的问题。根据社区反馈，也有一些OpenJDK用户遇到了性能问题。而Oracle JDK作为商业软件，在稳定性方面要好很多。
