By Every Java quarterly release bundles security fixes together with hundreds of bug fixes, performance changes, and other code modifications. For platform teams responsible for production stability, that volume of change creates a regression testing burden that routinely delays security patches by weeks or months. The result is a forced choice between application stability and security compliance.
In this interview on TFiR, Simon Ritter, Deputy CTO at Azul, walks through how the CPU and PSU release tracks work, why the distinction matters for platform teams, and how a two-phase deployment strategy eliminates the trade-off between patching fast and patching safely.
Guest: Simon Ritter, Deputy CTO at Azul
Show: TFiR
Here is what every platform engineer and Java operations team needs to know.
Technical Deep Dive
Q: What is the difference between a Java Critical Patch Update (CPU) and a Patch Set Update (PSU)?
Simon Ritter, Deputy CTO at Azul, explains that Java updates are issued four times per year on a fixed schedule: the second Tuesday of January, April, July, and October. Each release comes in two forms. The CPU contains only security-related changes, typically around 10 patches. The PSU is the full update, bundling those security fixes together with bug fixes, performance improvements, and other code changes, totaling 300 to 500 modifications.
“If you look at the number of changes that you have in terms of security patches, that’s typically round about 10, less than 10. If you look at the total number of changes in a full update, that’s going to be of the order of 3 to 500.” — Simon Ritter, Deputy CTO, Azul
Q: Why does the number of changes in a Java update affect regression testing burden for platform teams?
Ritter frames it as a probability problem. A larger change set introduces more opportunities for an update to interact unexpectedly with existing application code. Teams running the full PSU must validate hundreds of changes before they can confidently deploy, which stretches the testing cycle and delays the security fix. A smaller change set, like the CPU’s roughly 10 patches, dramatically reduces the surface area that needs to be validated.
“If you’ve got a very large number of changes, there’s more chance of that happening. Very small set of changes, less chance of it happening.” — Simon Ritter, Deputy CTO, Azul
Q: How should platform teams sequence CPU and PSU deployments to reduce risk?
Ritter recommends a two-phase approach. In the first phase, teams deploy the CPU immediately after release. The small number of security-only changes makes regression testing fast, and systems are brought into a secure state quickly. In the second phase, teams run fuller testing against the PSU. Once they confirm application behavior is unchanged, they roll out the complete update. If the PSU introduces a problem, teams can engage Azul support, receive a targeted fix, and redeploy without having left systems unpatched in the interim.
“It’s giving you that flexibility that means you can get your systems as secure as possible by using the CPU versus the PSU.” — Simon Ritter, Deputy CTO, Azul
Q: Which Java distributors provide both CPU and PSU release tracks?
Ritter credits Oracle with originating the CPU and PSU model. Azul has adopted the same approach for its OpenJDK distributions. According to Ritter, Azul is the only OpenJDK distributor outside of Oracle that provides customers with access to both the CPU and the PSU, giving enterprise teams the same two-track flexibility that Oracle customers have had.
“Azul is the only company that provides OpenJDK distributions other than Oracle that provides both of those CPU and the PSU.” — Simon Ritter, Deputy CTO, Azul
Resources & Documentation
- Azul JVM Security, Azul’s resource hub covering Java security patching, CPU and PSU release tracks, and OpenJDK support options
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: You mentioned patching. I want to talk a bit about that. There is a distinction you make between security only critical patch updates or CPUs and standard patch set updates or PSUs. Why does that distinction matter so much when it comes to regression testing burden for platform teams?
Simon Ritter: Yes. And this is very important as well because as you quite rightly point out, we have what’s called the CPU and the PSU essentially when an update is issued for Java, and that happens four times a year. So it’s very regular, it’s very well organized, very well documented. We know that on the second Tuesday of the month of January, April, July and October, there will be an update to the Java platform. Great. But what’s delivered is an update that contains the security patches, but it also contains lots of other stuff as well. There’ll be bug fixes, there’ll be some performance improvements, some other code changes. And if we look at the number of changes that you have in terms of security patches, that’s typically round about 10, less than 10. If you look at the total number of changes in a full update, that’s going to be of the order of 3 to 500. So there’s a lot more chance that you know that nervousness about the update breaking your applications. If you’ve got a very large number of changes, there’s more chance of that happening. Very small set of changes, less chance of it happening. So if you look at what Oracle and Azul deliver. So Oracle started this idea and Azul has followed this, which is that we provide our customers with both what’s called the cpu, the critical patch update, and the P, which is the patch set update. Now the CPU is only the security changes, so that 10 changes. The PSU is the sort of 3, 4, 500 changes. When it comes to deploying that update, it’s much easier to go. Right. We’ll deploy the CPU because only small set of changes get that system secure. Everything works nicely. Great. Then we can do more testing with the full update. Once we’re happy that the application works the way we expect it to, then, then we can roll that out. If there is a problem, go back to the support organization of Azul. Say our application is not working the way we expect it to, we can fix that, issue a new patch and then get that system up and running again. So it’s giving you that flexibility. That means you can get your systems as secure as possible by using the CPU versus the psu. And it’s worth saying that Azul is the only company that provides OpenJDK distributions other than Oracle that provides both of those CPU and the PSU.
