While the OpenJDK project has advanced Java development and the use of its source code and distributions are typically free to use, commercial support is not provided. Let’s examine the viability of self-support (whether that’s building your own distribution of OpenJDK or using one freely available) vs. the benefits of commercial support from an OpenJDK provider to meet your company’s application DevOps and security goals.
Keep up with quarterly updates
The OpenJDK community typically releases updates once per quarter. These updates come with critical improvements, such as security patches, performance updates, bug fixes, and new features. If you’re considering self-support, calculate the time and resources it would take to download OpenJDK source code and build your own JDK and test it rigorously (via TCK tests and against thousands of applications for proper coverage) versus relying on 24/7 commercial support to ensure all your security patches, bug fixes, and enhancements are current. Compare these OpenJDK commercially supported distributions, where there’s a 24/7 formal support channel across phone, email, or phone backed by support-ticket SLAs. Additionally, commercial support can proactively notify you of out-of-cycle bug fixes and provide deep root cause analysis for symptomatic issues, something you won’t get just by reporting bugs via the Oracle Java Bug Database where there are no assurances from the OpenJDK community on timing of resolution.
Backport security fixes as a best practice
If you are self-supporting and building your own OpenJDK distributions, you should backport security fixes, especially if you are running older Java version applications. Security fixes are designed to patch vulnerabilities in the software. By backporting security fixes in new versions (for example in Java 17 or Java 21) to earlier versions of OpenJDK (for example Java 6, 7, or 8), you ensure your systems remain secure against known threats. Not backporting could leave your systems exposed to these vulnerabilities, which attackers could potentially exploit.
Your business may run applications on older versions of Java for various reasons, such as compatibility issues, stability, or cost considerations related to upgrading. Given that Oracle ceased premier support for older yet popular versions like Java 6 and 7, you may desire platform continuity. But risk concerns remain top of mind. Using commercially supported builds of OpenJDK means you can continue to run older versions of Java without compromising on security. Plus, the move will keep your compliance department satisfied that the software you’re running meets enterprise data security regulations.
if you are using Java 7 or earlier, which Oracle no longer supports, you are open to critical vulnerabilities.
Stabilized security sensibility
Stabilized security builds for OpenJDK are crucial for consistent security, stable functionality, proactive protection, legacy system support, and cost savings. How a commercial provider delivers backported security fixes is essential to understand. Given that any change can endanger application stability, a commercial support package from an OpenJDK provider should deliver two update versions: a Critical Patch Update (CPU) and a Patch Set Update (PSU) to ensure a maximum level of security balanced against the need for rapid deployment with limited testing. For more information, read Explaining PSU and CPU in our support section.
Bundling technology is the better choice
By providing various technologies in a single bundle, commercial support packages can offer cost savings and performance optimization compared to purchasing support for these technologies separately. Bundled technologies are typically selected and configured to work well with OpenJDK, reducing the time and effort required for installation, configuration, and troubleshooting. This can significantly improve efficiency and reduce the risk of compatibility issues.
With the benefits of commercial support, you’ll also receive regular updates and patches for the bundled technologies, ensuring you benefit from the latest features, improvements, and security fixes. When technologies are bundled as part of a commercial support package, the support provider typically takes responsibility for maintaining and providing support for these technologies. One example of a legacy bundle is Oracle’s JavaFX, which was bundled with Java 8, 9, and 10.
However, JavaFX is excluded from the OpenJDK main project. If you run Java 8, 9, and 10, you may require formal JavaFX technical support. Best of all, if you encounter issues with older Java bundles, you have a single point of contact, which can simplify troubleshooting and resolution.
Open-source code defense
The use of open-source software has made development teams more productive and efficient. However, if you use software which includes GPL (GNU General Public License) source code in your own software application, it can add significant IP risk without taking proper precautions due to GPL’s requirement to make the entire combined code base available for review and reuse. This is often called “GPL contamination.” How can you best protect your Java code from GPL contamination given OpenJDK’s extensive use of the GPLv2 license?
Applications which access GPLv2 code only by way of APIs that explicitly carry the Classpath Exception are protected from additional licensing requirements and GPL contamination. But verifying Classpath Exception compliance is complex, and compliance must be verified anew with every build and every update. Not every file in OpenJDK carries the Classpath Exception, and a given Java version can have tens of thousands of source files. Careful analysis is required to assure that every API that is accessible by applications includes the Classpath Exception. OpenJDK distributions regularly miss inclusion of the Classpath Exception for all APIs, thereby exposing code using that distribution to GPL contamination.
Azul scans every source file in every build of Azul Platform Core and Azul Platform Prime to ensure customers are protected from contaminating code that would impose open-source license requirements on customer software. As a result, Azul’s JDKs are the only OpenJDK distributions that provide complete IP protection and assurance again GPL contamination.
Stabilized security builds for OpenJDK are crucial for consistent security, stable functionality, proactive protection, legacy system support, and cost savings.
In-house vs. Java commercial support
If the calculated costs and risks of in-house Java JDK/JVM support are too great and you’ve decided to explore OpenJDK commercial support options, remember that not all commercial support vendors for OpenJDK offer similar services and capabilities. In RFPs, evaluate support plans and SLA details across quarterly update assurances, backported stabilized security builds, bundled technologies, and open-source license contamination defense.
Azul is a leading OpenJDK provider that offers Java commercial support in addition to the Azul Migration Workshop, which includes an ITSM tool-built JDK inventory, migration roadmap, and resource steps. Whether you seek advisory services, additional staffing, project management support, or full delivery, Azul’s Java Migration Services can help fill in your team’s gaps.