0

On my machine, yesterday, I had installed and configured 6 java versions:

  • JRE 6
  • JRE 7
  • JRE 8
  • JDK 6
  • JDK 7
  • JDK 8

I believe an update was installed last night and today, both JRE 6 and 7 are missing (in 7, the lib folder is still there, as jars from it might have been locked by running applications). JDKs are perfectly fine, same is JRE 8.

After checking on a different machine (windows as well), the same thing happened: JRE 7 missing almost completely.

Did any else experience this? If yes, what is the cause? Is it an Oracle "feature" to remove older JREs?

I should mention that we have application which for various reasons need 6 or 7, and cannot be updated to 8 at this time.

Thanks.

Adrian B.
  • 1,592
  • 1
  • 20
  • 38
  • when you say you check on a windows machine , what are you meaning? you opened the java config and at installed versions , there were versions missing? – AntJavaDev Sep 09 '15 at 11:43
  • I checked the installation folder. It still has the 6 folders, but they are either empty or just contain the lib folder. – Adrian B. Sep 09 '15 at 11:45
  • Oracle has been known to delete older JREs during updates recently - which, IMO, is perfectly fine. It was hell-like to install an update and have JRE 1.6.0_10, 1.6.0_11, 1.6.0_12 (ad infinitum) on your machine. If you need to support older versions, you can always configure your IDE to compile for Java 6 and/or test against the SDK. – Marcelo Sep 09 '15 at 11:45
  • JAVA_HOME points to various java installation, as needed per application – Adrian B. Sep 09 '15 at 11:45
  • @Marcelo, do you have any articles on the subject, please? – Adrian B. Sep 09 '15 at 11:46
  • well thats true about Oracle update process , but if i remember correctly , there is a prompt before updating the java version , asking the user if he wants to delete any previous version found – AntJavaDev Sep 09 '15 at 11:47
  • @AntJavaDev no prompt. Both machines – Adrian B. Sep 09 '15 at 11:49
  • well in oracle's troubleshooter , i checked this article : The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u20) will expire with the release of the next critical patch update scheduled for October 14, 2014. – AntJavaDev Sep 09 '15 at 11:57
  • and also as i told you earlier , they have this article too : The Java Uninstall Tool is integrated with the installer to provide an option to remove older versions of Java from the system. The change is applicable to 32 bit and 64 bit Windows platforms. See Uninstalling the JRE. – AntJavaDev Sep 09 '15 at 11:58

1 Answers1

3

Yes, it's a feature. In the Java 6 times it was not, and it ended up in a library hell with dozens of versions of the JRE installed at the same time - something that, in theory, should not be needed as those versions are supposed to be compatible with each other.

As the documentation says:

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

...

As we did when JRE 6 was replaced by JRE 7, we have auto-updated users of the older release to the newer version of Java.

If you need to support older environments, you can set your compiler's compliance level. You will not be able to use newer features of the language, but it should run just fine.

You can also keep multiple JDKs installed and use that to test - the JRE comes bundled with it, so you just have to browse to that folder on the command prompt and compile with javac and/or start your app with java.

Marcelo
  • 4,580
  • 7
  • 29
  • 46
  • This is a terrible solution to updating a JRE! If you have a Windows service that runs Tomcat (for example). The JRE that is running on the server is automatically deleted and will not function correctly. Never delete the 'bin' directory of an active running java.exe process, prompt the user to correct the JRE without blowing up the application. Geez!!! – npn_or_pnp Feb 08 '16 at 21:02