I am having java JDK version 11 and JRE version 8, it will occur any problem in feature or not? is it mandatory to have same jdk version and jre version?
If your code is using features of Java 11, you will need the JRE 11 to run it. But as long as you develop your code against JRE 8, it doesn't matter which JDK you use to develop and compile with.
You can set your project in your IDE to a compatibility level of JRE 8 (like here). This prevents any usage of features newer than Java 8.
Example: Develop with JDK 11 but only use features from Java 8 -> code will run in JRE 8. See the older versions as subsets of the newer ones.
If you compile code targeting Java 8, and don't use any newer APIs, you can run it on either.
If you build for Java 11, but try to run on Java 8 it won't work.
The simplest thing to do is to use the JVM the software was built on (or a newer version)
No. Because you never use both of them at the same time.
JRE is Subset of JDK.
JDK includes the Java Runtime Environment (JRE), an interpreter/loader (java), a compiler (javac), an archiver (jar), a documentation generator (javadoc) and other tools needed in Java development.
If you Open your JDK folder (C:\Program Files\Java\jdk1.8.0_152) , you can find JRE there.
Coming to your Question; No it is not necessary to have both JDK and JRE of same version as we don't use both at the same time.
Related
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.
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.
Does VS Code (code-runner extension) support JDK 1.8? In the morning I was using JDK 12 , but then I downgraded to JDK 1.8 to try out applet viewer and stuff. Unfortunately now it doesn't even highlight the code.
Someone please tell me the problem and its solution.
JDK 1.8 is supported by VSCode.
Read https://code.visualstudio.com/docs/languages/java and install needed extensions.
Update 2021
Currently to use the Java extension in VSCode its required JDK 11, but you can still use older versions of JDK in your projects. See this to get information about how to configure other JDK version for your project.
Java 1.8 was no longer supported since "Language support for Java" extension upgrade to 0.68.0, I downgraded to 0.64.1 which works for me.
As stated here:
Note: Although the Java language server requires JDK version 11 or above to run, this is NOT a requirement to your project's runtime.
This means that you need to have JDK 11 or higher installed. You can also install older JDKs and configure the runtimes. Just open the Command Palette (Ctrl+Shift+P) and type the command Java: Configure Java Runtime. If you have JDK 8 installed and have properly configured maven or gradle, this isn't even necessary. Visual Studio Code will correctly pick up the correct JDK.
VS Code no longer supports JDK 1.8. The "Java Extension Pack" relies upon "Language Support for Java(TM) by Red Hat" which documents Java 11 is the minimum requirement. See here: https://marketplace.visualstudio.com/items?itemName=redhat.java
Tis unfortunate, guess I'm switching back to eclipse
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.
I was wondering if there is any difference running/building a software under JDK 8 and using compiler compliance level 1.7 vs JDK 7 as system default? I am more interested in reference to Android building, building apps, Eclipse, Android Studio, etc.
Yes, there are loads of new classes in the JDK 1.8, for example, the java.time classes. You won't get those if you build in JDK 1.7; but you will be able to use them if you build in JDK 1.8 with compiler compliance level 1.7.
Yes there is a difference between running/building a software under JDK 8 and using compiler compliance level 1.7 vs JDK 7 as system default.
running a software under JDK 8 and using compiler compliance level : You compile in jdk 1.7 but run on 1.8. No problem, your programm will work as needed.
JDK 7 as system default : You compile in 1.7 version and run on the same version.
I am wondering in waht case you would like to use the first case ?
truck load of difference actually. With JDKs the the compliance level is a directive to the compiler to specifically use the optimizations and linking features for the version you specified. It has a lot more going under the hood but I don't think you want to know that. New JDK versions bring new features and the compilers in those version are able to understand and link those features when building class files or assembled code of your source Java files. Consequently the JVM runtime in those JDKS is also equipped to handle such optimizations and cases and process them. So without compliance levels the class file that you build with JDK8 would only run correctly with JDK8 based runtimes. They may not do so with JDK7 or 6. To counter this problem and thus allow your JDK8 compiled code to run on JDK8,7 and maybe even on 6, hyou need to add compliance level to compiler directives accordingly. Downside is that you may not be able to use some latest features which the compiler offers but such cases are far few and outweigh the need for interoperability and potability.