Oracle Will Stop Providing Security Updates for Java 6 Next Month

The last publicly available release of Java 6 is to be released on February 19th 2013. After that date all new security updates, patches, and fixes for both the runtime and SDK of Java SE 6 will only be available through My Oracle Support, and will therefore only be available to users with a commercial license with Oracle.

In view of this, at the end of last year Oracle began automatically replacing instances of Java SE 6 with Java SE 7 via auto-update. In the announcement, Oracle said that they

The Java auto-update mechanism is designed to keep Java users up-to-date with the latest security fixes. To achieve this goal Windows users that rely on Java’s auto-update mechanism will have their JRE 6 replaced with JRE 7.

In December 2012 Oracle will start to auto-update a sample of users from JRE 6 to JRE 7 to evaluate the auto-update mechanism, user experience and seamless migration. Oracle will then start auto-updating all Windows 32-bit users from JRE 6 to JRE 7 with the update release of Java, Java SE 7 Update 11 (Java SE 7u11), due in February 2013.

This is absolutely astonishing. Oracle has decided that, in order to fix extensively-reported security problems, they will not only update Java 7 (their latest version of Java), they will also completely delete a completely separate product. Yes, Java 6 is a separate product from Java 7. They can be installed side-by-side, and many users have both Java 6 and Java 7 installed on their machines. Some of their applications depend on Java 6, and others might depend on Java 7, and these dependencies are typically hard-coded or configured to point to the correct, and different, file locations. Can you imagine if Microsoft released an update to .NET 4.0 that also removed .NET 2.0? This is just as serious.

Worse, it appears that they are taking it upon themselves to replace installations of Java 6 with Java 7 even if the users have only Java 6 on their machines.

As a result, he says, "You should strongly consider turning off automatic Java updates".

InfoQ spoke to Citrin to clarify his position. "I actually think the best thing that the user could do is update their browser plug-in to the latest Java 7," he told us, "or simply disable Java in the browser." He also had a number of suggestions for how Oracle could deal with the current situation

a. Change from side-by-side installs to in-place installs -- Java 7 gets installed in place of Java 6. That would require strict backward compatibility to older versions so that the user would not notice. Probably not a good option at this time, but would have been the best long-term answer.

b. Continue providing updates to Java 6 for at least a little while longer. Kicks the can down the road, but ultimately doesn't solve the problem.

c. As part of the Java 7 update, check whether the user’s Java browser plug-in is something other than Java 7. If not, switch it. This would probably be the best all-around solution. Most of the attacks come through the browser, and most people wouldn't notice. It would be unlikely to break anything.

Oracle has in fact taken a number of precautions with the update process. For enterprise users the most important is that the Java auto-update process updates only the latest version of Java on a user's Windows machine - if you have multiple versions of Java installed, only the most recent one will be replaced. In addition, where an enterprise manages the Java versions on behalf of users, auto-update is generally turned off and therefore they won't be affected. That said, Citrin tells us that whilst enterprise customers should not be affected by auto-updates, it has happened "according to the customer we spoke to. They’re an ISV, and they had several customers report problems."

The subject of silent automatic updates for Java was also discussed on the security conference call last week. This isn't a silent update, of course, but as with the Ask toolbar, users often click through installers without reading them, a point that Citrin also made when we spoke to him. Given that, it is interesting to review Donald Smith's comments on auto-updates in this context

The challenge is of course that you get - if that was a feature that came out, you have an ecosystem with a long history of it not working that way, and you would suddenly have a large segment of people saying, "How do I prevent this from happening?"

As Java is increasingly targeted by malware and virus writers, it is certainly a challenge for Oracle to encourage users to keep up-to-date.

InfoQ did contact Oracle for clarifications on this story but they declined to comment.

The real question is when will Oracle start providing security updates that actually work for Java 7? If they can't secure Java 7 it doesn't matter if they EOL Java 6.

The problems that Java started having under Oracle's stewardship come from Oracle's management culture. In Oracle's culture engineering expertise doesn't matter. Only management matters.

Oracle bought a large group of excellent engineers when they bought Sun, but instead of making personnel decisions based on merit they made decisions on which project someone was working on or whether they "fit" into Oracle's culture. James Gosling didn't fit so good bye James.

If you've ever worked with one of Oracle's Java based products or with Oracle consulting's Java consultants you've seen how bad Oracle's Java products are and how mediocre their Java engineers are. Oracle's Java offerings suck and the same mediocrity that pervades the ranks of their Java engineers is afflicting the JRE and JDK.

I don't expect any improvement in the problems that Java has had recently until stewardship of the JDK/JRE is taken over by an organization that demands engineering excellence.

I say this with great regret because Java has been my career for the past 15 years, but it's time to face the truth. Oracle won't do any better with Java than Adobe did with Flex. The management at those companies just doesn't care enough about engineering excellence. Their managers are fine with shipping defective products.

The real question is when will Oracle start providing security updates that actually work for Java 7? If they can't secure Java 7 it doesn't matter if they EOL Java 6.

First, the issues and exploits being raised (and the ones that I assume you are referring to) date back long before Java 6 or 7 -- for example, the ones related to Java Applets in a web browser, and separately, the use of Hashtable/HashMap on a server to store HTTP parameters for an HTTP request (which is not in and of itself a security bug).

Second, the security updates for Java 7 have been developed by Oracle and have worked -- but there were several latent problems that were exploited over a series of months.

Third, the overall approach to Applet security is in the process of being tightened to eliminate that entire class of vulnerabilities altogether.

The problems that Java started having under Oracle's stewardship come from Oracle's management culture. In Oracle's culture engineering expertise doesn't matter. Only management matters.

First, as I already said, these are not problems that "Java started having under Oracle's stewardship". These are problems that date back many years.

Second, engineering is very important at Oracle. I'm not sure what talk show you heard this on, or what open source blog you read it on, but your claim is a trifecta of ignorant, inflammatory and insulting.

Management of the JDK and JVM, for example, is under Georges Saab, who was the manager for the JRockit JVM before that. That is a dedicated team of managers and engineers that has come together from Sun and BEA into a single team at Oracle. While this may be an uncomfortable thing to consider (since it seems to run contrary to your bias), Oracle's level of engineering investment in the JVM and JDK is far higher than the level that Sun had before the acquisition.

Oracle bought a large group of excellent engineers when they bought Sun, but instead of making personnel decisions based on merit they made decisions on which project someone was working on or whether they "fit" into Oracle's culture. James Gosling didn't fit so good bye James.

It was disappointing to lose James (even though he wasn't working on the JVM or JDK), and it is true that he did not feel like he could "fit". However, he was certainly not forced out, pushed out, or fired as you suggest.

We lost quite a few engineers before, during, and after the acquisition. Many of them were extremely talented, and we continue to wish that we could have retained more. Nonetheless, as I said previously, Oracle's level of engineering investment in the JVM and JDK is far higher than the level that Sun had before the acquisition.

If you've ever worked with one of Oracle's Java based products or with Oracle consulting's Java consultants you've seen how bad Oracle's Java products are and how mediocre their Java engineers are. Oracle's Java offerings suck and the same mediocrity that pervades the ranks of their Java engineers is afflicting the JRE and JDK.

I'm not sure how to respond to such a rational argument as yours.

The people who are working on the JVM and JDK are (for the most part) the same people who were working on it in the past -- including many whom Sun had taken off of the JVM and the JDK -- as well as the engineers who were working on BEA JRockit and engineers that Oracle has since recruited like Atilla Szegedi (Rhino).

Also, to the best of my knowledge, Oracle has not transferred any engineers from "bad Oracle's Java products" or any "Oracle consulting's Java consultants" to work on the JVM or JDK. Please correct me if I am mistaken.

Oracle won't do any better with Java than Adobe did with Flex. The management at those companies just doesn't care enough about engineering excellence. Their managers are fine with shipping defective products.

There are a lot of things that need to improve with Java at Oracle, but most of those things are not new to Java at Oracle. Further, the management and the engineers that I interact with in the Java organization are committed to engineering excellence.

Lastly, you may have noticed that Java is more open under Oracle than it ever was in its history. OpenJDK allows you -- or anyone -- to participate in any way that you can. Unfortunately, that openness has also contributed to the finding of some of these long-latent issues in the software. While that is unfortunate, it is a process that other open source software packages -- like Apache and Linux -- have gone through in their history as well. Java will come through this series of trials, that much stronger from the experience.

Peace,

Cameron Purdy | Oracle

And in the interest of full disclosure, I do work at Oracle, but the opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.

Cameron, if these are issues that existed for years, why only now are we hearing respected security experts telling us we should disable or remove Java? Maybe there is a rational answer for that. I would like to hear it.

My "bias" about Oracle comes from two and a half years of working along side Oracle consulting on a government project. That project, which was an enterprise project of average complexity, was cratered by Oracle consulting at a cost to the tax payers of $41 million dollars. It was a project that easily could have and should have succeeded. It failed because Oracle consulting was the primary source on the project and they rotated people through the project who were marginally qualified or completely unqualified to be on the project.

During your time at Oracle have you encountered Oracle's abomination called BC4J? That was the technology that Oracle demanded that we use instead of Hibernate or EJB 2.1. They tried (unsuccessfully) to remove Struts from the project in favor of their own proprietary MVC framework (I forget it's name). It was all about vendor lockin even if it threatened the project.

One of my colleagues who was also an independent contractor on this project said (only half-jokingly) that he thought the first project manager that Oracle put on this project was mentally retarded.

We had Oracle's most expensive technical support, which was typically useless. They knew less about their own products than we had learned. I'll never forget one call I made to Oracle's technical support. The support engineer asked me how to setup and configure Oracle's J2EE container (this was before Oracle bought BEA).

I could go on, but you get the picture.

I understand your loyalty to Oracle. They made you rich when they bought Coherence. But for many of us our experience with Oracle's Java products has been a disaster. And I am seeing evidence of this same incompetence in this series of serious security problems with Java. Problems like these didn't occur under Sun's stewardship. Maybe there is a logical explanation, but I haven't heard it yet.

if these are issues that existed for years, why only now are we hearing respected security experts telling us we should disable or remove Java? Maybe there is a rational answer for that. I would like to hear it.

These "security experts" make their money by making a big name for themselves. Finding exploits (rarely) and pontificating on the exploits found by others (often) is the name of their game.

To the best of my knowledge, the exploits that have been shown over the course of this past year were all targeting old bugs, and in one case targeted a partial fix of an old bug.

During your time at Oracle have you encountered Oracle's abomination called BC4J? That was the technology that Oracle demanded that we use instead of Hibernate or EJB 2.1. They tried (unsuccessfully) to remove Struts from the project in favor of their own proprietary MVC framework (I forget it's name).

Yes, I have heard of BC4J. Regarding the framework, perhaps you are referring to ADF. Both date back quite a ways and have had their share of issues. ADF has matured quite a bit (e.g. it's now used extensively and successfully in many of Oracle's own applications), but it was never closely aligned with typical Java EE standards and frameworks, and initially it can be quite off-putting coming from something like Java EE 6 or Spring.

My "bias" about Oracle comes from two and a half years of working along side Oracle consulting on a government project. That project, which was an enterprise project of average complexity, was cratered by Oracle consulting at a cost to the tax payers of $41 million dollars. It was a project that easily could have and should have succeeded. It failed because Oracle consulting was the primary source on the project and they rotated people through the project who were marginally qualified or completely unqualified to be on the project.

If true, then that is awful. Oracle Consulting (which is a completely different part of the company from the product groups) has quite a few good consultants, and I've personally seen a lot of successes (and I've invested product engineering time in mentoring more than a few consultants); I've also seen some pretty bad and mediocre ones and I've done what I could to help weed them out.

I understand your loyalty to Oracle.

Loyalty to a corporation doesn't make sense at all to me. I do have a great deal of loyalty to our customers and to the people whom I work with, and I endeavor to be a good steward for the business and the people with which I am entrusted. That is all.

Peace,

Cameron Purdy | Oracle

And in the interest of full disclosure, I do work at Oracle, but the opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.

Just to be clear you are saying that there is no real need based on the merits to disable Java in the browser as recommended by Carnegie Mellon and and the Department of Homeland Security?

* I did not actually make any suggestions with respect to that technical question, so I am confused why you would suggest that I am saying such a thing.

* I am neither acting as an Oracle spokesperson nor giving you advice as a security professional.

* On my own computers, I do have Java installed (often many versions of Java), but I have Java applets disabled by default in my web browsers. I enable Java applets only for sites that I trust (from both a security and privacy standpoint), and typically only for the duration corresponding to the use of some specific Java-based functionality. This is my personal approach, and one that I used long before any of these security exploits were found.

Peace,

Cameron Purdy | Oracle

And in the interest of full disclosure, I do work at Oracle, but the opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.