Two Dangers of Oracle Java SE You Need To Be Aware Of
Oracle’s Java SE is the largest commercially supported distribution of Java due to the extensive use of Java within the Oracle product set. The version of Java will determine the extent Oracle will support it – and to whom it will support. Since the changes from Oracle’s Java SE from freeware (with exceptions) to requiring a commercial subscription, there are two aspects that you need to be aware of if you are considering using Oracle’s Java SE in the future.
If you want to learn about the recent changes (2018/2019) to the Java ecosystem by Oracle, please see the detailed blog on the changes at the end of this post.
The first danger you need to be aware of is the use of virtualisation with Java.
Oracle has an unfriendly stance on virtualisation. As part of obtaining information about a Java subscription from Oracle on behalf of a client I was asked about the client’s use of virtualisation. I was hesitant to give out any details of the client’s use of technology and upon asking why Oracle was interested, I was told that a client cannot mix a Java SE Subscription (which is required for production instances) with the free Oracle Technology Network (OTN) Java SE license (which is what is normally used for non-production instances) on the same physical server. This would not apply if your server is “hard-partitioned” using accepted technologies and practises from Oracle which can be achieved with Solaris Zones, UNIX LPARS and Oracle’s OVM. However, not with VMWare nor Hyper-V.
Oracle and virtualisation have a dubious track record. In the world of database and license compliance, Oracle and VMWare and Hyper-V mix like oil and water. We have noted that the database audit scripts from Oracle now capture Java usage as well as virtualisation information. In time they will no doubt build capability to capture Java usage in non-Oracle database environments as the Java SE Subscription includes the rights to audit. Whilst that is highly unlikely to occur in 2020, the normal modus operandi for Oracle is to let customers use their products without question for a significant time and then later invoke their rights to audit your usage.
Whilst I won’t delve too much, Oracle has a strange notion that all VMWare clusters in particular are connected and they want you to have licenses for CPU cores on all clusters that have any ability to connect in any way. This can be countered to an extent by isolating the shared storage of the clusters, however it is your decision on how you would address Oracle if they make these claims. Our advice is, be aware of your contractual commitments that you have made with Oracle and enforce your rights.
The second danger of Oracle Java SE is that Application Vendors are moving away from Java SE and instead testing and delivering new versions of their products on OpenJDK. This is important. Because Oracle have now made Java SE a commercially paid requirement for customers in most circumstances, it is impacting the customers of the Application Vendors. At Pebble IT, we are specialists in license compliance, including Java, and on behalf of clients we obtain their application vendor’s direction in the use of Java. In all cases but one, the Application Vendors we have discussed this with are testing and releasing current and future versions of their application with Java OpenJDK. This does not mean it will not work with Oracle Java SE, however it is possible that the vendor might not even test with Oracle Java SE.
This represents risk to your applications. You may seriously wish to consider restricting Oracle’s Java SE just to your Oracle products and have OpenJDK as your main Java strategy for everything else. At Pebble IT we envisaged difficulties for clients with the use of Java SE, and as a result we have partnered with Azul Systems who are the leading provider of commercial support for OpenJDK and are a leading maintainer of OpenJDK for JDK6 onwards. Contact us for a discussion on how you can obtain professional 24x7 support of your Java ecosystem across multiple versions without worry of virtualisation and knowing that this is the distribution that your application vendors are testing their products against.