At first glance, one might look at the first ten Java 7 updates in eighteen months (through JRE7u11, u8 was not released) and feel like the sky is falling. But, let’s split those apart into functionality updates (planned) and security updates (unplanned), and maybe it's not quite as intense.

Functionality updates

First, the functionality updates, and what we see here are evenly spaced feature enhancements. These are the even numbered releases which signify a planned release.

Java 7 Functionality Updates.png

Security updates

Then the odd-numbered (and unplanned) security updates. Wow! Don’t those look just as regular as the feature releases!

Java 7 Security Updates.png

Let’s take a look at these six security update packages in a bit more detail.

 

The first shocker is that right out of the gate, in the first three months of existence, twenty security vulnerabilities were identified. What you might not know is that nineteen of those vulnerabilities also existed in Java 6, and had existed in Java 6 for the previous five years. Only one of these was unique to Java 7. Maybe even scarier: Nine of them still exist in Java 5! In fact, this is pretty much the story for almost all of these Java 7 vulnerabilities.


Here’s a chart showing the number of Java 7 vulnerabilities reported/fixed up to JRE7u11 that also existed in Java 6 and Java 5.

Java 7 vulnerabilities in older Java versions.png
Last Friday, Oracle released another security update for Java, (JRE7u13 and JRE6u39), and we can presume that JRE6u39 will be the last update for Java 6. If the above numbers shocked you, this security update might add a bit more of a shock. The update itself repaired 50 vulnerabilities, but eleven of them were only in the JavaFX module. The other 39 were in the Java Runtime Environment -- Yep! They fixed 39 more vulnerabilities! But only six of those vulnerabilities were exclusive to Java 7! Of the 39, 12 of them only existed in Java 6, and 21 of them existed in Java 6 and still exist in Java 5. One of the vulnerabilities didn't exist in Java 7, but only in Java 6 and earlier, so only 38 of them existed in Java 7.


So, if update the above table and add one more row and recalculate the totals, here's what we have today:

Java 7 u13 vulnerabilities in Java 6.png

Let’s put this in a very simple perspective:  over 80% of the reported/fixed vulnerabilities in Java 7 also existed in Java 6 (and have for the past six years) and almost half (49.6% to be exact) still exist in Java 5!

 

Which Java to keep?

What that means for patch administrators is that there’s no significant advantage to deferring the deployment of Java 7 and retaining Java 6, except in a case where an application has a known and verified dependency on Java 6. If that situation applies to you, be aware that after February, 2013, Oracle will not be publishing any additional security updates for Java 6, and you might want to have a heart-to-heart with that software vendor who still has Java 6 dependencies.

 

For some additional guidance on managing Java installations, see my Patchzone article.


Who’s responsible?

Excluding the 61 vulnerabilities that exist in Java 5, which Oracle definitely inherited from Sun, we might wonder about the other 38 vulnerabilities in Java 6. In fact, we can infer their “state of inheritance” by the version of Java 6 in which they were fixed: Every one of those Java 6 vulnerabilities existed in JRE6u26 and earlier. That is to say, all 80% of the Java 7 vulnerabilities that also existed in Java 6 were inherited from Sun!

 

Which, I guess, leaves us with this reality: Oracle inherited a problem in Java code security from Sun in 2009, and over the past eighteen months we’ve learned that a lot of them were not discovered, much less fixed, in Java 7. So we can’t really blame Oracle for creating them -- well a third of them are unique to Java 7 -- but there’s no doubt that Oracle is complicit in their perpetuation of a lot of bad code written in Java 6 and earlier.(Some of these vulnerabilities actually date back to Java 1.4 and earlier!)

So, I think I’ll temper my anger towards Oracle, at least as to their perceived ineptness in creating new code; however, as for the rest, I guess it really depends on where you are on the spectrum with regard to accountability for inherited conditions. Up until recently, I think, the prevailing wisdom in American popular thought regarding “inherited problems” would have placed all of this in the lap of Sun Microsystems.

On the other hand, regardless of where you point the finger, it’s definitely Oracle’s problem now.