Oracle to Change the Release Numbering for Java SE

| by Charles Humble Follow 572 Followers on May 14, 2013. Estimated reading time: 3 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

"To avoid the confusion caused by renumbering releases", Oracle has announced that it is adopting a new numbering scheme for JDK 5.0, JDK 6 and JDK 7. Minor Java releases are divided into planned Limited Update releases that include non-security related bug fixes and occasional new functionality, and Critical Patch Updates (CPUs) that only include fixes for security vulnerabilities. The increasing frequency of security releases means that planned releases occasionally have to be re-numbered. This causes problems for Oracle since it means fixes and enhancements can't be assigned to specific releases in bug tracking systems.

To work around this Oracle has decided that:

  • Limited Update releases will be numbered in multiples of 20.
  • We intend for Critical Patch Updates to continue to use odd numbers. The numbers will be calculated by adding multiples of five to the prior Limited Update and when needed adding one to keep the resulting number odd.

This is best illustrated with an example:
The next Limited Update for JDK 7 will be numbered 7u40, and the next 3 CPUs after that will be numbered 7u45, 7u51, and 7u55. The next release will be a Limited Update 7u60, followed by CPUs 7u65, 7u71, and 7u75.

This numbering scheme will leave several numbers between releases which will allow us to insert releases – for example security alerts or support releases, should that become necessary - without having to renumber later releases.

Whilst noting that he wasn't involved in the discussions around this, Oracle's Phil Race, who has been an engineer on the Java client team at Sun/Oracle over 12 years, provides some more details on the OpenJDK mailing list

There's become something of a convention that security update releases are odd numbers and other releases are even numbers. I'm not sure how important that is to the outside world but if two security releases happen without a release in between you need to decide if you want to break that convention.

We also had a lot of confusion arise from the need to do a few unplanned releases. Builds of 7u14 existed, bugs were marked as fixed in that release, reports, stats, etc all referred to that release but all that data is now wrong, and that work is now going to (hopefully) see the light of day in 7u40. In the interim, internally and externally people couldn't understand why a bug supposedly fixed in 7u14 was reproducible in 7u17. So leaving a very generous gap between non-security release numbers means we should not have to do the re-numbering on the fly.

Leaving gaps between planned security release numbers mean there's already a place set aside in case any unplanned release has to happen. Keeping the odd numbering convention for security release uses up more numbers. So that's how you end up with such inscrutable jumps in numbers.

eg :
7u15 was a planned security release
7u17 was unplanned, using a reserved number (I think)
7u19 was reserved just in case, but not needed
7u21 was a planned security release
and so forth ...

Oracle notes that a more elegant solution would require the changing of the version numbering scheme to accommodate different kinds of changes (for example by using 7u44-2 ). However this cannot be implemented outside of a major release, since doing so might break existing code that parses version strings (possibly including the Java auto-update system), in a way vaguely reminiscent of what happened when it changed the company name from Sun Microsystems to Oracle. Moreover, it is unlikely to make the change in time for the much delayed Java 8 release.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

"in time for the much delayed Java 7 release" by Matt Giacomini

Did you mean Java 8?

Re: "in time for the much delayed Java 7 release" by Charles Humble

I did! Thanks for the comment; now corrected.

Re: "in time for the much delayed Java 7 release" by Henry Bowman

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you