Java Runtime Environment deleted after update? - java

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.

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.

Related

How to run java applications JDK13 on JRE?

I have made an a java app with JDK 13. I created a exe file with launch4j. But nobody can run it because everyone has the jre 1.8 version and it wont start... I has to include the java jdk 13 with installation and set the java_home with that ?
TL;DR - If you want to distribute a Java 13 application, the best option is to use jlink to create the executable. This avoids the user having to install any JDK or JRE to run your code.
Clearly, users cannot run your application with a Java 8 JRE or JDK. A typical Java 13 application will make use of features that are not present in the Java 8 platform. But even if it worked, free Java 8 will be end-of-life in April 2021, and at that point:
It will stop getting security updates, making it (in theory if not practice) unsafe for your customers to use.
It will be more difficult for your customers to find free Java 8 binaries. (Paying Oracle for a license will be an option though.)
But Java 13 is problematic too. That will be end-of life in September 2020! And besides, JRE distributions are no longer available.
Finally, application installers with embedded JREs were always somewhat problematic:
It was easy for software suppliers to forget to update the installer when there was a security patch to the JRE.
It was difficult for system administrators to add the embedded JRE to the list of things that were automatically updated. Especially if they allowed end-users to install the application for themselves.
The best approach will be to do the following:
Use jlink to create the distributable for your application for all platforms that you support
Update to Java 14 as soon as practical
Whenever a Java patch release with security fixes is released, assess what has been fixed and (if warranted) create new releases of the distributable for your customers to install.
If you don't want use jlink, another alternative would be to develop your code to run on Java LTS releases. (The current LTS release is Java 11, and the next one will be Java 17 which is planned for September 2021.)
Using an LTS release would allow you to release your code as JAR files.
Embedded JREs are a bad idea; see above.

Java JDK 11 Breaking Old Jars/Programs

It is to my understanding that Java JREs are backwards compatible, if you write a program in Java (JDK) 7, it will run with Java (JRE) 8.
I have a couple of programs I developed in Java 8, and have .jar and EXE files that I built when I finished them, and they always ran fine. However, after installing Java JDK 11 (11.0.2), these old .jar files break...
A couple of them still run, but their GUIs have expanded, with buttons and images being bigger than before, and in some cases blurry
One program just doesn't run at all, trying to run it in a console gives an exception: "Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: javax/activation/ActivationDataFlavor"
I understand that this class and some other javax classes have been removed from JDK 11, so from a development standpoint you couldn't use them anymore without a tool such as Maven. But I do not understand why installing JDK 11 has any effect on my old jars, as I didn't install a new JRE, and even if one came with it, it should be backwards compatible?
Too add to this, I use Apache NetBeans 10, it worked fine with Java 8, but after I installed JDK 11, NetBeans 10 still ran but its loading window was big and blurry, and the IDE's images are blurry, and all the text is bigger.
So why is installing JDK 11 having these negative effects on older programs?
Note - I have tried associating the jars/EXEs with javaw.exe from JRE version 8 (201), however, they all still have the same issues.
Java tries to be backward compatible but sometimes breaking changes are necessary to evolve the ecosystem. Until now breaking changes were shipped with major release e.g. Java 9, 10, 11. In your case you are most likely affected by Java 11's JEP 320: Remove the Java EE and CORBA Modules.
Remember that Java 8 was released in 2014. For 5 years Oracle and the Java community provided patches and security fixes for Java 8 but doing this forever is impossible.
The issue you are facing is likely not an incompatiblity w.r.t. the bytecode. It is just a missing class.
Java 11 dropped the support of some old technologies - for example Java Applets. If you run a Java 8 Applet in a Java 11 JDK / JRE you will get a ClassNotFound exception just because Java 11 does not provide the class / jar.
Similarly for JavaFX, which still exists, but is not longer part of the Java Distribution. You have to add it as a separate Jar.
I believe it would be possible to add these classes to a project. Personally I would like to see a port.

Why is JRE 10 outdated and JRE 8 up-to-date?

I (as a non-Java kind of guy) am puzzled that my local JRE 10 installation required an update, but when updating, I get the JRE 8! This is even reported on https://java.com/en/download/more_info10.jsp:
Users who installed JRE 9 and/or JRE 10 (non Long-Term Support Releases) should remove those out-of-date versions of Java.
I would understand if JRE 11 would be the current version, but no, it's JRE 8:
If you still require Java on your computer download the latest release of JRE 8 available at java.com, which is the only currently supported major release of Java targeting desktop deployment.
How can this be?
The explanation is right there on that page you linked and quoted.
Relevant section highlighted.
"desktop deployment".
If you still require Java on your computer download the latest release
of JRE 8 available at java.com, which is the only currently supported
major release of Java targeting desktop deployment.
Short answer:
Java 9 and 10 are not a Long Term Support (LTS) release, and have expired.
Java 8 commercial supports end January 2019, public updates for personal use through December 2020 though.
Java 11 is the current and is also a LTS support release.
So todays choice is between java 8 and 11. But 11 removed applets and browser integration and other desktop technologies (JavaFX, java webstart etc). See list below and link to source. See also the Oracle white paper of 2018-03, Java Client Roadmap Update.
Further details:
Oracle has decided to stop releasing several variants of JRE on their own. As well as requiring a license for production use for newer releases. For example 32bit variants are no more, traditional desktop variants not available as there is no no java webstart and javafx is separated out since jdk 11+ etc, Oracle is more focusing on 64bit and server.
Put together with the fact that 9 and 10 are not Long term support releases (and they have expired) this leaves you with the choice of Java 8 for this particular use case for now.
JDK public updates for java 8 from oracle will end in January 2019 (and December 2020 for personal use) so at least until then is the current desktop java version of choice, from Oracle that is.
The current version of java 11, is only available as a 64bit JDK (development kit download) from oracle. No suitable desktop JRE (just the runtime).
Removed in JDK 11 release from Oracle:
Important Changes and Information
The following are some important changes in and information about this release. In some cases, additional details about the changes described below are provided in these Release Notes.
The deployment stack, required for Applets and Web Start Applications, was deprecated in JDK 9 and has been removed in JDK 11.
Without a deployment stack, the entire section of supported browsers has been removed from the list of supported configurations of
JDK 11.
Auto-update, which was available for JRE installations on Windows and macOS, is no longer available.
In Windows and macOS, installing the JDK in previous releases optionally installed a JRE. In JDK 11, this is no longer an option.
In this release, the JRE or Server JRE is no longer offered. Only the JDK is offered. Users can use jlink to create smaller custom
runtimes.
JavaFX is no longer included in the JDK. It is now available as a separate download from openjfx.io.
Source: https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html
Simple: Oracle's own support roadmap lists Java 8 as having "premier" support until 2022.
Conversely, Java 9 and 10 have had their premier support lapse in March and September of 2018. Oracle's new update model ensures that non-LTS releases from Java 9 onwards are only officially supported until the new version of Java arrives.
"Current" is a bit of a strong word when it comes to Java; technically, the latest version of Java that should be used by end consumers is Java 11 (as of time of writing), since that is the current LTS. However, not all applications which use Java may be up-to-date, so it's safest to fall back to Java 8 until your application vendor informs you that it's safe to upgrade.
Perhaps that's because Java 11 deprecated modules which are present in Java 10 e.g. JAXB or Java FX. Latest Java 8 still has these modules so the software that worked on Java 10 can potentially work with Java 8.

Changes required to migrate from Oracle JDK to OpenJDK

We are planning to migrate our project from Oracle JDK to OpenJDK. I have some questions regarding the same.
After doing some analysis I found that OpenJDK will have a feature release every 6 months which is only supported until the next feature release.It's essentially a continuous stream of releases targeted to developers. Now my question is will it be a good idea to migrate to OpenJDK. Because if the
above statement is correct then we need to upgrade OpenJDK in our application every 6 months
Ref : Differences between Oracle JDK and OpenJDK
What are the basic changes required to do this migration. When I say basic changes, I mean I need to understand in very high level.One thing I know that is
Oracle JDK and Open JDK are having different jar licences. So do I need to replace all Oracle JDK jars with OpenJDK jars as its mentioned in
Migrating to OpenJDK from Oracle JDK ?
Currently we are using :
JDK 1.8
Tomcat 8
Windows Operating System for development. Services gets deployed in linux OS
Maven Build tool
Appreciate your help.
Thanks
Now my question is will it be a good idea to migrate to OpenJDK
For Java 11 you might want to, though by Java 11 they will be almost identical.
So do I need to replace all Oracle JDK jars with OpenJDK jars
I would install a version of OpenJDK and use the JARs which came with it. I wouldn't mix and match them.
JDK 1.8
I am not sure gain anything by migrating Java 8. Oracle Java 8 is still supported at least until Jan 2019. After that, you might not get any update, but you might not with OpenJDK either.
If your concern is getting support for Java 8, I suggest contacting a company which will give commercial support Java 8 such as Azul for what seemed like a reasonable price. https://www.azul.com/downloads/zulu/zulu-windows/

Issues running Java applets

Recently I'm studying Java. I had no real troubles while building normal java files to .class and execute them, but, when I started a bit with applets I haven't been able to run anything.
Before I had started Java, as developer I had already a lot of development tools (Eclipse, Visual Studio, CodeBlocks and others). So, basically, I already had JDK but downloaded it again to get updated to 1.8.
Now, I have also JRE 8 and there are no troubles in using javac.exe and java.exe to build and execute, but, after building the .class file of applet, when I load the html page, I got an error which strongly recommends me to upgrade JRE.
Just to translate it:
Current version of Java is obsolete.
Upgrade (recommended choice)
Block
Later
If I do the update, it gets me to this page http://java.com/it/download/index.jsp), but, it's the download link of JRE 1.7. As much as I know, JDK 1.8 is not beta (it's accessible a 1.9 preview) so why shall I use 1.7? Indeed, after downloading and installing, when I try to run the applet, the message above is shown again.
Is actually possible to install JRE 1.8 on Google Chrome?
I resolved it. It wasn't easy since it wasn't a real trouble of java.
I had effectively Java 7 version 55 and Java 8 (but also 7-45 and 6). Java 8 was 64-bit while Java 7 was 32.
Google Chrome (32-bit browser) used so the last version it could use. According to Oracle, it's recommended to remove older versions of java (because of security) so I removed everything but the 8, and then switched to 64-bit browser (Chromium). I left older JDK installed for compatibility development reasons.

Categories

Resources