When is the next Java update?

"Java update available -- a new version of Java is ready to be installed..."

This occurs four times a year: January, April, July, and October.

Oracle Java SE is updated on the Oracle Critical Patch Update schedule. The date for these updates is published a year in advance. This schedule helps system administrators manage software across a fleet of systems. Combined with another feature, the security baseline, client systems can detect newer security updates and adjust their behavior by offering an update and decreasing the client’s attack surface.

System Administrators can use Deployment Rule Sets to control compatibility if they need a version below the security baseline.

The Security Baseline

The security baseline received new behavior in Java 7 update 10 (December 2012), combining it with the JRE expiration date. Prior to this, it has identified which Java versions contain the latest security patches since JDK 1.4. There is a different baseline version for each major Java version: Java 6, Java 7, and Java 8. The JRE will identify that it should be updated in two main ways:

• The JRE will periodically check the security baseline to see if a new version is available. If it detects that it is below the security baseline, it will consider itself to require an update to a version that meets the security baseline requirement.
  The schedule for this periodic check can be controlled by system administrators.
• If clients cannot obtain the security baseline for any reason, they will eventually reach their built-in expiration date. This expiration date is published in every release note, but it is typically a month after the next scheduled critical patch update.
  This expiration date is built in and cannot be controlled.
• For example at time of writing (November 2015), the current security baseline for Java 8 is 1.8.0_65. The next scheduled Critical Patch Update is January 19th. The expiration date for Java 1.8.0_65 is February 19th.

In addition to Critical Patch Updates, there is another release type called a Patch Set Update(PSU), which contains additional non-critical changes. Although a PSU version is numerically “above” the security baseline, the PSU contains the exact same critical patches as the corresponding CPU at the security baseline. Example: At time of writing, the security baseline is 1.8.0_65. A different patch set update, 1.8.0_66, is available with additional changes. Users that only want critical patches do not have to deal with these changes yet, and can test them separately. In the next scheduled Critical Patch Update, we will include those changes from 1.8.0_66.

What happens when the security baseline changes or the expiration date passes

When clients detect that it is below the current security baseline, they will typically do two things: prompt end-users to install the newer update, and decrease the potential attack surface of the installed JRE.

These changes are described in the Rich Internet Application Deployment Process under the question, “Is the JRE expired or below the security baseline.” Desktop administrators that need to control prompts and/or use Java versions below the security baseline may do so through Deployment Rule Sets, under the question, “Does a rule exist for this RIA.”

The attack surface reduction applies to Rich Internet Applications (through browsers).

Planning for updates

With the dates of Critical Patch Updates published a year in advance, system administrators should plan ahead to roll out Java updates onto client systems. Deployment Rule Sets should be used with applications that cannot use the latest Java Runtime Environment for one reason or another, to whitelist which known-safe application can use specific older JREs. Critical Patch Updates are available to Java 6 and Java 7 through the commercial Java SE Advanced, along with other management tools.

Administrators needing to deploy Java across thousands of managed systems every quarter may consider the commercial Java SE Advanced, which offers tools to better manage Java at scale. Examples of these commercial features include:

•  An enterprise MSI installer to support easier customization and deployment.
• Critical Patch Updates for older versions of Java beyond public support (e.g. Java 6 and Java 7).
• The Advanced Management Console, to help build an application inventory of Java applications and create a Deployment Rule Set from tracked usage.
• Java Flight Recorder and Mission Control, for deep performance analysis.
• Support from an experienced team that can monitor and track Java bugs.
  

Additional Resources

• Introducing Deployment Rule Sets
• Deployment Rule Sets by Example
• Advanced Management Console
• Video Walkthrough
  
• Managing Multiple Java Versions