Java 7 update “silently” deletes Java 6, breaks applications

Monday, Jan. 28th 2013

Software updates shouldn’t do unexpected things. They particularly shouldn’t remove software other than what they’re ostensibly updating, and they shouldn’t break running applications. It’s even worse when this all happens automatically and without warning.

The other day, one of our customers, an ISV that uses JNBridgePro in one of their applications that includes both Java and .NET, told us that several of their customers had reported that their applications stopped working after the customers updated their installations of Java 7. The strange thing is that the applications didn’t use Java 7; they used Java 6. The problem was fixed by reconfiguring JNBridgePro on those machines to point to Java 7 rather than Java 6. Our customer asked us whether JNBridgePro had problems with this update, or with Java 7. We answered that there should be no problem: JNBridgePro works fine with both Java 6 and Java 7, including the latest updates.

Something odd was going on, so we started digging deeper. Running the auto-installer for the new Java 7 update, we saw the following screen, with the relevant message buried in it:

Then we found the following notice on the Oracle website:

About the Java 6 Auto-Update to Java 7

Oracle will start auto-updating Windows 32-bit, Java Runtime Environment (JRE) users from JRE 6 to JRE 7 in December 2012.

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.

  • JRE 7 has been the default version on since April 2012 and is now being used by millions of users.
  • As we did when JRE 5 was replaced by JRE 6, we will auto-update users of the older release to the newer version of Java.
  • As always, all users are encouraged to update to the most recent Java versions available for public download.
  • In February 2011 Oracle announced the End of Public Updates for their Java SE 6 products for July 2012. In February 2012 Oracle extended the End of Public Updates for 4 months, to November 2012. See:
  • • Oracle is now extending the End of Public Updates again for 4 additional months to provide developers and users with additional time to migrate to Java 7. The last publicly available release of Java 6 will be in February of 2013 with the release of Java SE 6 Update 39 (Java SE 6u39).

Java 6 End of Public Updates extended to February 2013

(Emphasis ours.)

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.

How is this different from, say, Microsoft updating Office by replacing one version by another? That’s an update-in-place, so hard-coded paths will often still work. Even so, updating one version of Office to another likely won’t involve an auto-update, but rather an explicit re-installation, and one would expect dependencies to break. Java 6 and 7, on the other hand, are side-by-side installations, and one doesn’t expect an update to one to affect the other in any way.

Let’s look at this from Oracle’s point of view. The security holes that they plugged in Java 7 likely also exist in Java 6, and they have stopped providing new updates to Java 6. Why not replace Java 6 with Java 7 and fix these problems?

This strategy might make sense for less sophisticated users who only use Java inside their browsers. They likely do not know which version of Java they have, or even if they Java at all. In this case, it makes sense to fix the problem by updating the Java installations, so that machines aren’t infected with malware by visiting rogue websites.

However, most of our customers aren’t using Java in their browsers. Their Java is running on servers, or in self-contained desktop applications that, if they connect to the Internet, only connect to specific sites. Their applications depend on specific versions of Java, or on Java files being in specific places. JNBridgePro’s shared memory mechanism, in particular, depends on an absolute path to a specific jvm.dll, but that’s not the only case where dependencies like this occur. With their update, Oracle has silently pulled the rug out from under many running applications.

Why do I say “silently”? Even though the update installer mentions that Java 6 “might” be removed, and the notice on the website says it “will” be removed, very few people will read the text in the installer; they will likely just click through it, since nobody expects a Java 7 updater to remove Java 6. And almost nobody will read the notice on the website unless they are specifically searching for it.

One could say that IT shops should turn off automatic updates, and apply updates in a controlled process after extensive testing. That’s true, but clearly auto-updates can still happen; it’s not reasonable to assume that all business users have sufficient IT support. After all, it happened to our customer’s customers. It’s also the case that a situation like Java 6 being removed in a Java 7 update might not be found in a controlled test, since most such tests will only try to see whether applications that use Java 7 will be affected. To make matters more difficult, the mechanism for turning off automatic Java updates isn’t obvious.

If you find yourself with a broken application that uses JNBridgePro and Java 6 after updating Java 7, here’s what you can do:

  • You can reconfigure your application (and particularly the JNBridgePro component) to use Java 7 rather than Java 6. JNBridgePro will have absolutely no problem with Java 7. Whether your Java code will work with Java 7 is something that you will need to determine yourself.
  • You can go to the Oracle Java website and download and reinstall Java 6. Then, you’ll be back where you were.

Finally, you should strongly consider turning off automatic Java updates. As I said it isn’t immediately obvious how to do this, since the Java control panel, by default, doesn’t display the Update tab that contains the switch that turns off updating. The Update tab only appears when the control panel is run as administrator. You can turn off the auto-update switch as follows:

  1. In Windows Explorer, navigate to your JRE’s bin folder (for example, C:\Program Files (x86)\Java\jre7\bin, although it might be different on your machine).
  2. Once you’re there, find javacpl.exe. Right-click on it, and select “Run as administrator.”
  3. Inside the control panel, you can now see the Update tab. Select it, then uncheck the “Check for Updates Automatically” checkbox.

The control panel will ask if you really want to do this. Trust me, you do. Then click on the OK button.

Note that if you do this, it’s your responsibility to make sure that your Java installations are up to date, and that you engage in good security practices. You will need to keep track of the latest Java security problems and the latest updates when they become available, and you can download them from Oracle’s Java site. The downloaded updaters will only update the specific Java versions, and they won’t pull the rug out from under you by removing completely different versions of Java that your software might depend on.

In summary, Oracle’s latest automatic Java update is dangerous and irresponsible because it “silently” removes software other than the software it ostensibly updates, thereby breaking running code. By all means update and secure the Java running inside browsers, but leave our server and desktop software alone.

13 Comments on “Java 7 update “silently” deletes Java 6, breaks applications”

  1. Donald Smith Says:

    Hi Wayne,

    I’m Donald Smith on the Java SE PM team.

    Oracle’s Java 6 is near the end of public updates. The upcoming release in February is the last public update. After that, users should be using Java 7. This shouldn’t be news to anyone in the Java ecosystem.

  2. Wayne Says:

    Hi Donald –

    Thanks for the reply.

    I understand that Java 6 will no longer be updated. I also understand that there are serious security issues in Java (6 and 7) that must be addressed. It seems reasonable to me to replace Java 6 with Java 7 in browsers, where much of the security problems surface. But completely removing an entire product (Java 6), and leaving nothing in its place (Java 7 resides in a different location in the file system), is not a good idea, since it will break software that depends on those paths.

    I have no particular fondness for Java 5 or 6, but our customers continue to use it, and we continue to support them. Removing a product from under them does these customers no service.

  3. ‘Silent but deadly’ Java security update breaks legacy apps – dev | Security-Vision Says:

    [...] had applied the latest Java update (Java 7u11). The software developer blogged about the issue here. Oracle has decided that, in order to fix extensively reported security problems, they will not [...]

  4. ‘Silent but deadly’ Java security update breaks legacy apps – dev | Gens News Says:

    [...] had applied the latest Java update (Java 7u11). The software developer blogged about the issue here. Oracle has decided that, in order to fix extensively reported security problems, they will not [...]

  5. ste williams » ‘Silent but deadly’ Java security update breaks legacy apps Says:

    [...] had applied the latest Java update (Java 7u11). The software developer blogged about the issue here. Oracle has decided that, in order to fix extensively reported security problems, they will not [...]

  6. Stephen Colebourne Says:

    The JRE is an end user tool that is a single product from the perspective of the end user. An upgrade removing the older version of the JRE is simply good behaviour, and what an application like Google Chrome would do.

    Removing JDK 1.6 would by contrast be poor behaviour, because the JDK is a developer tool, and developers should know what they are doing.

    Your blog post doesn’t seem to mention which you refer to. Moreover, your suggestion to blindly turn off updates is like telling users to switch off Microsoft Windows Updates – something liable to result in more security holes in the wild.

  7. Wayne Says:

    Interesting point about the distinction. I would say, though, that my point is equally valid whether it applies to the JDK or the JRE. In the case of the users I was referring to in my original post, they were using JRE 6 to run their application (the choice of the customer who built the application used by the end user). The application used JNBridgePro to run a JVM and Java code inside the .NET process. This capability uses JNI under the hood, and it requires a path to the chosen JRE’s copy of jvm.dll. (Essentially, we have implemented a custom Java launcher.) By removing JRE 6, this path was no longer valid, and the application broke. They reported it quickly and the fix was easy (point to JRE 7′s jvm.dll), but it was an inconvenience to the customer that should not have occurred. How many other applications have been broken by this change that have not been as quickly diagnosed or as easy to fix?

  8. Ross Says:

    “Can you imagine if Microsoft released an update to .NET 4.0 that also removed .NET 2.0?”

    That’s kinda like what they did with the release of .NET 4.5. You don’t actually have 4.0 anymore, it just overwrites all the 4.0 dlls and tries to be identical to it.

  9. Wayne Says:

    True, which is why I didn’t use that example. One slight difference is that 4.5 is really just an overlay on 4.0. The core DLLs are still 4.0, and it didn’t seem to break existing code. The 4.0 DLLs that are distributed with applications still work, and are still in the GAC, where they can still be found by existing applications. If Oracle could have done something similar with Java (difficult, but probably not possible due to the way Java is organized on the file system), there might not have been grounds for complaint.

  10. Oracle's Java security head says the company will 'fix Java,' communicate better Says:

    [...] had applied the latest Java update (Java 7u11). The software developer blogged about the issue here. 'Silent but deadly' Java security update breaks legacy apps – dev ? The [...]

  11. James Says:

    We use a web product from Adobe that is only certified with Java 6 (and users report problems with when using Java 7). Thanks for this info. I somehow missed that Java 6 was being desupported. An auto-upgrade for us to Java 7 would have probably been a disaster.

  12. Episode 837 – Silent but Deadly, Don’t Blame Us, & Me Too! | InfoSec Daily Says:

    [...] JNBridge, which provides Java and .NET interoperability tools, reports that customers of software providers who use its technology came a cropper in cases where users had applied the latest Java update (Java 7u11). The software developer blogged about the issue here. [...]

  13. Java on BES - BlackBerry Forums Support Community Says:

    [...] Re: Java on BES I read, that the very recent update will remove java 1.6 without further warning from your Machine. This will brick the BES most likely JNBridge Blog xxx8211; Java 7 update [...]