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.
Related
I'm new to Eclipse and Java. Whenever I run the Java program in Eclipse there is a major.minor 52 exception. I want to know which version of Java is supported by Eclipse Helios. My computer is Windows 7 32-bit OS. So I can't download any other version of Eclipse. Please help me with a favorable answer.
The class file major.minor version 52 error means that Java 8 or newer is required.
Eclipse Helios (3.6) is very old (10 years and 14 releases old). It probably doesn't understand anything above Java 6.
There are 32 bit version of Eclipse newer than this.
Eclipse 4.9 (2018-09) was the last 32 bit Eclipse - that supports Java 8.
OK. Lets start with some history.
Eclipse Helios (3.6) was released in 2010. It supported the latest version of Java that was available at the time; i.e. Java 7.
Eclipse Juna (4.4) was the first release of Eclipse to support Java 8 language features.
Java 7 has been end-of-life for a few years now.
Java 8 (the oldest available version of Java with free support) was released in 2014. This corresponds to the classfile version number (52) of the application that you are trying to run.
Java 8 is also that last version of Java for which you can get a Windows 32 bit version from Oracle.
So what can you do?
If you want to run a pre-built Java application which has classfile version 52, you will have to download and install Java 8.
If you are prepared to rebuild the application, then depending on the application you will probably still need to upgrade to Java 8 to do that. (It depends on whether the application uses Java 8 language constructs or library classes and methods that were introduced in Java 8. It is likely that one or both of those is true.)
If you are going to upgrade to Java 8, it would be advisable to Eclipse to (at least) Luna, but you could go all the way to the 2018-03 release ... which is the last version that supported 32bit Windows.
You could probably also run the application from the command line; i.e. without using any IDE at all. But that would apply to a tool that was designed to run as an Eclipse plugin, etc.
But my strongest advice is to get a machine that can run a 64 bit OS. You can probably get one for USD $300 or less. If your current hardware cannot run a 64bit OS, it must be pretty old, and I am surprised that it still works reliably.
Which version of Java is supported by Eclipse Helios?
Java 7 and earlier versions.
So I can't download any other version of Eclipse.
That is not true. But simply upgrading Eclipse won't solve the problem. You need to upgrade Java as well if you want to run that application.
I am about to start a new GUI project utilizing Scala and JavaFX/OpenJFX.
Last time I was involved Java 8 was state-of-the-art, JavaFX was integrated with both JDK and JRE and Scala used JDK 8 for building, Jigsaw was not there and Oracle provided (free) (bug) fixes almost forever.
Now, a few years later, things have changed rather dramatically: Java 11+ is what we are supposed to use, JavaFX has been unbundled and its development is continued as OpenJFX (more or less) independently to Java, Jigsaw is there and Oracle forces the users to upgrade their environment every 6 months.
That changes would not be too bad if it wasn't for the fact that Scala still seems to operate on JDK 8, OpenJDK builds do not include JavaFX, and AFAIR, OpenJFX is not available to Java version prior to Java 11.
All that leads me to the question: What tool stack would one use to implement a Scala application using JavaFX/OpenJFX as GUI toolkit?
Is it safe to use Scala with JDK (not JRE!) 11+?
Oracle forces the users to upgrade their environment every 6 months.
As noted in the comments, this is not true. You can still use JDK 8 even. If you want Oracle LTS, use Java 11. There are other companies that give LTS to other OpenJDK versions (RedHat JDK, Azure JDK...). Mark Reinhold (Chief Java Architect) explained this many times in his talks (1, 2 or any of his talks that he has repeated 3 times a year for the last 2 years).
What tool stack would one use to implement a Scala application using JavaFX/OpenJFX as GUI toolkit?
I'm not a Scala developer, but use whatever latest OpenJDK build Scala allows you to, and depending on if and what support you need, whichever OpenJDK version is supported. I'm willing to bet OpenJDK 11 will answer all your needs.
JavaFX has been removed from the Oracle JDK, but was never bundled in OpenJDK JDK1. You can easily bundle OpenJFX2 as a dependency when using OpenJDK, either as external JARs or through a dependency manager (Gradle, Maven...). The JavaFX/OpenJFX website is https://openjfx.io and contains instructions on how to do it.
JavaFX/OpenJFX versions are released in parallel (more or less) to the JDKs and supports 1 versions back of OpenJDK (OpenJFX N supports JDK N-1 and JDK N, and maybe JDK N-2...). So, if you use OpenJDK 11, you can use OpenJFX 11 or 12. OpenJFX 13+ could work, but it is not guaranteed.
Is it safe to use Scala with JDK (not JRE!) 11+?
If your Scala version supports it, OpenJDK 11+ and OpenJFX 11+ are safe. Note that the JRE has been removed from the JDK, so it's irrelevant.
1 OpenJDK JDK is the right way to refer to it, like Oracle JDK, but most people just use OpenJDK.
2 OpenJFX is to JavaFX what OpenJDK JDK is to Oracle JDK, but OpenJFX and JavaFX are used interchangeably since there's no real difference.
Our company is planning to move towards AdoptOpenJdk 11 from Oracle JDK8 with Wildfly 10 running on it. All the code and wildfly server will be same(written and supported by JDK8) and since java is backward compatible, I think that it should work theoretically, but are there any issues that we have to be aware of?
There are a lot of updates from JDK 8 to JDK 11. I would recommend just moving to AdoptOpenJdk 8 in the short term. Your specific code may be ok, but you also have a huge set of dependencies that may be using something that needs updated. For example, what is your build tool? Gradle needed to be updated because it needed a newer version of ASM. Are you using JAX-RS? Jersey 2.27 doesn't work on Java 11.
JavaEE is in a weird place right now because Oracle basically dumped it on the Eclipse foundation (now called JakartaEE). It will take a little while for it to be sorted out.
I have migrated from openjdk-8 to openjdk-11.
Steps I follow:
1. Add missing Java dependencies in jdk11
2. Upgrade/remove supported plugins (Need to upgrade ASM to 7.1, cglib or other byte manipulation libs)
3. Change JAVA_OPTIONS related to GC.
4. Wildfly support for java11
More details on libs versions check the link
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.
This may seem a daft question so I will be as brief as possible.
Where I work, we deal with lots of Java apps that are compiled on old versions of Java, in fact we recently upgraded one of them to Java 1.6
We've been given new laptops recently with no admin rights and Java 7 installed by default.
I am presently unable to get hold of and install a copy of JDK 1.5 (which I need)
In Eclipse, if I set my JDK Compliance level to 1.5 but the Installed JRE is 1.7
Which of these 2 statements is true... ?
1. I am building my code at Java 1.5 ?
2. I am building my code at Java 7 ?
I've seen and spoken to various people on this subject and I am still non-the-wiser.
It means the byte code that is generated from your source code will be compliant to the 1.5 JRE.
The syntax highlighter will not allow you to do things that were new to 1.6, 1.7 such as switching on strings.
Developing with a JDK higher than the target platform is in principle possible, using the "compliance settings" and/or target version switches with javac.
Its however not practically feasible for doing real development, as nothing will prevent/warn you from using the API's present in your installed JDK but not in the target platform.
If, for example you develop for java 1.4 using an installed 1.5, while the compiler will not let you use autoboxing (which was introduced in 1.5), but it will happily let you use (for example) Integer.valueOf(int). Which is not present in 1.4.