We Keep Coding

Java versions confusion

I want to install Java on a few different servers for running a third party service on tomcat.
I am not a Java developer and I got a bit confused when I began searching for the installer.
I checked the different Java versions and their long term support dates.
It seems that Java 11 JDK is - LTS so i decided to use it.
But when I was trying to find a runtime version (JRE?) since this is the version I am supposed to install on the server(?) I only found Java JRE 8.X.X, and this got me confused.
There is no higher major version of the JRE?
How does it work if you use the JDK 11 or even 14-15 as a developer and then use Java 8 JRE on your deployed servers?
Maybe the JDK holds inside of it the Java 8 JRE version?
Or do you actually need to install the JDK version on the servers instead?

The JRE is a subset of JDK. It contains everything needet to run Java applications but no support for development. So, if you need a JRE, a JDK is also good, although it conatins much stuff that you will not need.
Normally, for executing a Java application, you need a JRE with the same version or higher than the JDK used for development. But the developer can advise the compiler to generate code for a lower version. If he does so, he cannot use the features of the higher versions. For example the compiler of JDK 1.8 can produce code for JRE 1.6. You should consult the manual, to see which old versions are supported by the compiler of a specific version.

After some research,
It seems there is no separate JRE section anymore.
Also JDK 11 for production is not free and I guess this is an ongoing trend for the near future.
On a side note there is the open JDK 11 version but it does warn you about outdated security updates.
So basically in my case sticking to updated Java JRE 8 version is good enough for the near future.

running java code in higher versions, compiled in lower java versions

I have java EE artifacts like .jar , .war, .ear files compiled and running in java 1.6 version. i wanted to run them (.ear file [.jar + .war]) in latest java versions like java 1.8.
Which Option would be the best considering moving to new java version.
1) Recompile Code in 1.8 and deploy to Application server
- to be at a little safer.
2) Just deploy to java 1.8
- No Code Compilation required (means .ear file generated using java 1.6). .ear file can be safely deployed to latest java 1.8 version
- probably we wont end-up having runtime issues ?
As this this is a production code base and no developer. Hence No Code changes in either cases, the only change is java version. I prefer going with Option-1, as compilation in higher version of exiting java classes to avoid any runtime issues.
Any thoughts ! or other useful options in this regard.
Thanks

As #Stultuske mentioned you only telling no code changes possible in either cases then your first case not valid one only.
But anyway as per java(Oracle) compatibility specification Java 8 is backward compatible with previous versions for sure no doubt about this except some very rare cases where binary incompatibilities happened.
For more information about this you can refer below stack overflow link --
Can newer JRE versions run Java programs compiled with older JDK versions?

Recently I did a similar thing but we updated the code/dependencies if needed.
I will suggest recompiling the code base first because this will tell you quickly if it or any dependencies don't support the newer Java version. If compilation is successful, then deploy to test environment and do sanity, regression, etc.
I hope you aren't talking about deploying to Production environment directly :)

Fast-ClassPath-Scanner does not work with java 6 runtime?

Fast-ClassPath-Scanner
https://github.com/lukehutch/fast-classpath-scanner using latest version.
On executing(get names of all classes in war which includes all jars and classes)
new FastClasspathScanner(basePackage).scan().getNamesOfAllClasses()
getting:
unsupportedclassversion error with jre 6
Please provide a solution to it or alternative to perform same.

FastClasspathScanner is compiled for java 1.7
When you try to load it in a 1.6 (JRE6) environment it fails with an UnsupportedClassVersionError. This error indicates that the class version (here 1.7) is not compatible with the JVM version (here 1.6).
Java 7 is not backwards compatible with Java 6. You could try to build the FastClasspathScanner library yourself unter 1.6 (not sure if that's possible). Or upgrade your project to Java 7.

Correct, I am the author of FastClasspathScanner, and it's not a goal to get this working with JRE6. However, patches for supporting 1.6 are welcome.

Create Jar Compatible With Java 7 With IntelliJ Using JDK8

I am using JDK8 on my normal desktop and I have a separate linux box that I am trying to run the Java program on.
The problem I'm running into is that the linux box is running jdk7, so the computer has JRE7 basically that it is running off of. My question is, is it possible to create a jar file in JDK8 that will be compatible with java 7?
I'm using IntelliJ to compile. I tried to compile in 1.7, but it gave an error when I did end up trying to do it. I compile it here:
In 1.8 it works fine to compile, but when I try to compile in 1.7 it doesn't work.
I know the short answer is to update the linux to JRE 8. But I am curious, is there a way to make it backwards compatible? Or is the other answer to simply install JDK7 on the desktop in order for it to run on the linux box using JRE7?

Java programs built with JDK 8 will only run on machines running JRE 8 (or higher).
I found this when trying to compile classes on my local Linux machine (using JDK 8) and deploying to a remote server running JRE 7. The classes just wouldn't work (like you're finding).
If you want to use JRE 8 on linux, I recommend using the oracle-java8-installer package from webupd8team. Installation instructions found here (assuming Debian based distro).
If you want to compile to JDK 7, it's not good enough to only have JDK 8 installed and pick to compile 1.7. You need JDK 7 installed to and restage your project to use JDK 7.
The thing you have to remember is that the difference between JRE/JDK versions is not just the extra features developers can use (e.g Lambda functions) but it's also that the JRE itself is improved (efficiency, garbage collection, etc.).
As a extreme example: If you wrote code that only used JDK 1 features but compiled it using JDK 8, it wouldn't run on a machine running JRE 1 because the Java classes had been compiled with JRE 8 in mind.
Do note though, that if you're Java Code uses only features from JDK 7 or 6 etc., you might think it good practice to compile using the minimum JDK required to allow for compatibility with more machines. Well...you'd have that compatibility but at a cost of using inefficient, out of date, possibly vulnerable compiled classes (At little extreme, but you get my point).

Are you using any new Java 8 features? Because if you are, this means you cannot build the project against the JRE7.
If you are not using any Java 8 features, you can build to Java 7 most easily by downloading the JDK7 and switching the project to use that instead of the JDK8.

You should also set project language level to 1.7 (and module language level(s) as well, if they're different). It's done in Project Structure settings dialog. After that the project should compile.
Note that you shouldn't use any of the APIs that appeared in 1.8, but such usages will most likely be highlighted in the editor.

JAVA Compilation : compile with new JVM version and run on older version

Here is a small explanation of my problem.
I have an application which was compiled with java 1.5. This application is installed on 2000 pc (blockboxes) installed at customer premisses.
The jar of my application is often updated to add new feature and fixes, but for technical reasons, it is not very easy to update the java version, so I must keep using Java 1.5 on those existing machines.
Few months ago, I got a request for a new requirement for this application. To fulfil this task I have added the usage of Hazelcast in this application.
My problem if the following:
- Hazelacast jar file needs Java 1.6 or above, so I must compile my application with 1.6
- The new functionality using hazelcast will only be activated on demand by settings a new parameter. This means that it will not be used in the 2000 already installed blackboxes.
- All new blackboxes will be installed with Jave 1.6 or above to be able to use the Hazealcast functionality.
My problem is that I want to have a unique source code and unique version of my application for old blackboses using Java 1.5 and new blackboxes using 1.6 or above.
In the beginning, my idea was to always compile with version 1.5 and make sure that the new functionality would only be activated in blockboses using java 1.6 or above. This option is not working, because when I compile with 1.5, the compiler complains that Hazelcast jar file needs 1.6 :(
The second option would be to compile with 1.6, but then I cannot be sure that my application will still work properly on all blackboxes using 1.5. :(
I'm would like to know if someone here would know how to solve this kind of problem?
Just let me know if my explanation is not clear ;)
Thanks in advance for your help.

JVM is Backward compatible.You can run almost all code from Java 1 on Java 8.
So the best way is to use the option two. Compile it with 1.6 on some testing machines. And if it works( which most probably will) you don't have to make much change to the application .

You can compile your code to Java 1.5 bytecode using JDK 1.6, just take care of the following:
-source=1.5 and -target=1.5 compiler options
bootclasspath should point to rt.jar from JRE 1.5
See this post for more info: http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html
The post also recommends simply building your application with older JDK if possible. You need to figure out a different build process and exclude incompatible libraries from the classpath. If you use Maven, consider having two pom.xml files, with an optional parent file.