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