Azul

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 closest Tuesday to the 17th 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

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

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 code 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)…

Both Azul and Oracle understand the world of production Java. Better yet, we have structured our platform-level updates to make deployment of new updates as risk-free as we can. At Azul, our Zulu Enterprise OpenJDK commercial support plans reflect that understanding and focus (as do our Zing subscriptions, for that matter.)

Unique to the Industry


Azul and Oracle’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 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?

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.

Contact Us

© Azul Systems, Inc. 2020 All rights reserved.