Currently set to Index
Currently set to Follow

224% ROI and payback in under 3 months for Azul Zing.
Read Forrester’s Total Economic Impact™ Study.

Slash your Java support costs as much as 90%!
We make it easy, safe and secure.


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: Security-Only Updates

This important quarterly build starts with the prior quarterly update and adds ONLY fixes for new security vulnerabilities. These 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 Quarterly Update

This quarterly build, generally available on a regular cadence, starts with the prior quarterly update and then adds a broad range of updates along with all the security fixes released by the OpenJDK project. These comprehensive updates include bug fixes and feature enhancements that can (and have) impacted critical code and have recently taken production Hadoop and Cassandra-based systems offline.

There’s only one challenge with “regular” quarterly Java updates:

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 standard Java update, deploy the security-only update ASAP, and thoroughly test the larger set of changes on your schedule, while staying protected from known security vulnerabilities.

Security-only builds often can go live within hours or days, while regular quarterly releases 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 support offerings to be production-oriented — we try 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 security-only and a standard quarterly update.

We are unaware of any free OpenJDK build that follows this practice. All other commercial OpenJDK builds (and all free builds, including Azul’s) will only ship a single 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 regular quarterly release 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 security-only updates that are 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

Still have questions?

We’ll do our best to explain why some OpenJDK build may be bringing your business more risk than you think, and we’ll help you with some affordable options.

Contact Us

© Azul 2021 All rights reserved.