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.’
