Keeping Java production systems secure and up-to-date can be an operational challenge. There’s always a balance between disrupting operations and reducing the risk of vulnerabilities. No time is that trade-off more apparent than the Tuesday closest to the 17th of the month (mostly the third Tuesday) of January, April, July, and October when the steward of Java releases new updates.
Java has been updated on a quarterly basis for many years, first by Sun and then Oracle — and those updates have been comprehensive, timely, and part of an unbroken cadence that goes back to Java’s earliest days of production operations with enterprise-class workloads.
While prior Java exploits were focused on desktops and browser-based attacks, the majority of new security issues are server-side.
Whatever their source, there is a standard way of getting fixes deployed on a quarterly basis that ensures the least impact when you have access to two binary updates:
- Binary 1: The CPU– aka Critical Patch Update. This quarterly build starts with the prior quarterly PSU and adds ONLY fixes for new security vulnerabilities. These CPU binaries are designed to be stable (i.e. minimal changes), and immediately deployable, with a minimum of testing and therefore a minimum of risk.
- Binary 2: The PSU — aka Patch Set Update. This quarterly build, generally available at the same time as the CPU, starts with the prior quarterly PSU but adds ALL the security fixes in the CPU PLUS all non-critical fixes, including bug fixes and feature enhancements, which can impact 100s of lines of codes and Java classes.
There’s only one challenge with PSU builds: They contain more changes to Java. And sad to say, the downside of ‘new features’ can be ‘new bugs.’
Every quarter, operations teams execute updates based upon one simple rule: if you don’t need a given bug fix in the PSU, deploy the CPU ASAP, and thoroughly test the PSU before the next update cycle so you can move quickly to deploy the next CPU.
CPU builds often can go live within hours or days, while PSU builds should generally take longer to verify.
And that brings us back to Oracle (and Azul)…
Oracle understands the world of production Java. Better yet, they structured their platform-level updates to make deployment of new updates as risk-free as they could. At Azul, our Zulu Enterprise OpenJDK commercial support plans reflect that same understanding and focus (as does our Zing team, for that matter — and they’ve been at it for a few years more than our OpenJDK engineers.)
Unique to the industry, Oracle and Azul’s commercial releases of Java SE (proprietary or OpenJDK) include both a CPU binary and a PSU binary. We are unaware of any free OpenJDK build that follows this practice. Other commercial builds (and all free builds, including Azul’s) will only ship a PSU as their quarterly OpenJDK update (you will sometimes hear it called it a CPU update, but these “CPU” binaries always include security updates and new features — making them a PSU build in all but name.)
So, how does that impact you?
If you are comfortable taking the time to QA a combined security and new feature update, you have many options.
If you want to get a CPU update that is rapidly deployable, you can talk to Oracle (their Java SE Support Subscription pricing is posted), or you can choose to do business with Azul (we post our pricing for Zulu Enterprise Support at https://www.azul.com/products/pricing/).
Still have questions? Send us a note at [email protected] and we’ll do our best to explain why PSU-only updates may be bringing your business more risk than you think, and we’ll help you with some affordable options.
