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.
Related
We are moving from Oracle jdk8 to OpenJDK 8. But our system has JavaFX code, which needs to migrate from JavaFX to OpenJFX.
I wonder what is the relationship between JavaFX in Oracle jdk8 and openjfx8. Can anyone explain for me?
Oracle unbundled and open-sourced JavaFX libraries
Oracle was bundling its own implementation of JavaFX with the Java 8 version of its Oracle JDK product.
Later, Oracle discontinued that bundle.
OpenJFX project
And around the same time, Oracle open-sourced its JavaFX implementation, making that source code a sub-project on the OpenJDK project. That sub-project is known as OpenJFX (as Oracle retains commercial rights to its “Java” branding). See its GitHub page, and its OpenJDK wiki page.
Oracle now shares leadership for OpenJFX development with the Gluon company. Gluon sells support, licenses for additional libraries, and services. Oracle may sell support as well.
OpenJFX is actively developed. A major release arrives around the same time as every major release of Java. Java 17 will released this month (2021-09), and OpenJFX 17 version is already available. JavaFX 17 requires JDK 11 or later. See Release Notes for JavaFX 17.
See the OpenJFX site for more info and developer documentation: https://openjfx.io/
Oracle JDK is built from OpenJDK
You said:
We are moving from oracle jdk8 to openjdk 8
The Oracle JDK product is based on OpenJDK. Oracle has committed to feature parity between them. The only differences are that (a) Oracle sells support for Oracle JDK and requires a fee when used in production (but not for development and testing), and (b) Oracle reserves the right to ship immediately any necessary fixes directly to its paying customers without waiting for the fix to wind its way through the OpenJDK process.
Options for deploying JavaFX/OpenJFX libraries
The current versions of Oracle JDK no longer bundle the JavaFX libraries. So no matter what distribution of Java you choose (Pivotal, Azul Systems, Microsoft, SAP, Amazon, BellSoft, Oracle, Red Hat/IBM, Adoptium/AdoptOpenJDK, etc.), you will need to address the issue of providing the necessary OpenJFX libraries.
One option is bundling the libraries with your app. The new jlink and jpackage tools might help.
JEP 282: jlink: The Java Linker
JEP 392: Packaging Tool
Another option is putting a copy of the OpenJFX libraries on the class path of your user’s machines.
A third option is using a JDK distribution that includes the OpenJFX libraries. At least two companies provide a variation of their JDK distributions that include OpenJFX:
ZuluFX from Azul Systems.
LibericaFX from BellSoft.
OpenJFX starts at version 11
You said:
But our system has javafx code, which needs migrate from javafx to openjfx?
I see only versions of OpenJFX numbered 11 through 18. Only OpenJFX 11 and 17 will have long-term support.
They recommend Java 16 for OpenJFX, with a minimum requirement of Java 11. So you may not be able to migrate your Java 8 based project to OpenJFX.
Suggestion: Migrate to versions 17
Java 17 is due this month, and is expected to be designated a long-term support (LTS) version. I suggest you consider updating your Java 8 app to Java 17 and OpenJFX 17. Both Java and JavaFX have evolved by leaps and bounds since versions 8.
First study the Answer by jewelsea discussing technical changes through the various versions of JavaFX & OpenJFX. Then carefully read through all the Release Notes for both product lines, keeping notes of any potential issues for your app. Then give it a try. Try converting, see what problems arise. Take a shot at fixing them. If you eventually succeed, you’ll be well placed for the future.
Resources
You may want to read these white papers:
Java Client Roadmap Update by Oracle (2020-05)
Java Is Still Free by Java Champions (2021-10)
Oracle Java SE Support Roadmap by Oracle (2021-04)
Background
This information is supplemental to Basil's excellent answer, which already comprehensively covers the majority of relevant information on this topic.
This question was specifically about JavaFX 8, which is now obsolete. The feature difference information here is provided for historical purposes.
It is highly recommended that any existing projects migrate from JavaFX 8 to a recent JavaFX version, and that any new projects use a recent JavaFX version (e.g. JavaFX 17+), which is based on the openjfx source.
What was Oracle JDK 8 and what was JavaFX 8 in OpenJDK?
Oracle JDK 8 was a distribution of the JDK and JRE which included an implementation of JavaFX 8.
JavaFX 8 was open-sourced as part of the OpenJDK project. You can find a link to JavaFX 8 source from the OpenJDK project at at the openjdk github site (external link may disappear or die some day in the future).
The Oracle JDK 8 was largely built from those open source components, plus a couple of closed source components as outlined below.
It was possible to build a complete version of OpenJDK 8 that included JavaFX 8 using only open-source code (less the features from the closed source outlined below).
However, many OpenJDK 8 based distributions (e.g. those that shipped as JDK and JRE implementations for common Linux distributions), did not include the JavaFX implementation portions of the OpenJDK project.
Also, third-party JDK distributions from vendors such as IBM also did not include a JavaFX implementation.
Thus, for JavaFX 8 development the primary distribution in use was Oracle JDK/JRE 8, not distributions that contained only the OpenJDK implementation for JavaFX 8.
Oracle JDK 8 and OpenJDK 8 source Implementation/Feature Differences
This information is based on info at:
JavaFX and OpenJDK
I can no longer find links to official sources on the net which describe these differences.
Oracle JDK 8 implements some features that are not available from the OpenJDK 8 open-source implementation. The components that relate to JavaFX:
The ON2 VP6 video codec, which is owned by Google and that Google had not open-sourced (when I last checked).
This means that an open version of JavaFX cannot play VP6 FLV files. This is not a big loss as it is difficult to find VP6 encoders or media encoded in VP6.
Other more common video formats, such as H.264 will playback fine with an open version of JavaFX (as long as you have the appropriate codecs pre-installed on the target machine).
The Oracle WebStart/Browser Embedded application deployment technology.
The lack of WebStart/Browser Embedded deployment technology is really something to do with OpenJDK itself rather than JavaFX specifically. This technology can be used to deploy non-JavaFX applications.
I think some versions of Oracle JDK 8 and the OpenJDK JavaFX implementation shipped with differing 2D renderers.
Oracle JDK shipped with a closed source renderer implementation and OpenJDK shipped with a different open-source renderer.
This was an internal implementation detail, I don't think there were any functional feature differences between the implementations.
Possibly some other minor differences that I am not aware of.
For most users, with the possible exception of the lack of WebStart/Applet support, the functional/feature differences between the two versions were immaterial.
There were differences in the licensing models for the Oracle JDK implementation that include JavaFX and JavaFX versions built purely from the OpenJFX project source within OpenJDK. If these licensing difference details are important to you, I encourage you to do your own research into the topic.
JavaFX 9 & 10
As of Java 9, VP6 encoding was deprecated for JavaFX, and the Oracle WebStart/Browser embedded application deployment technology was also deprecated.
So, although this functionality was included in these releases in the Oracle SDK and not the OpenJFX source, the technology was already marked for future removal (which occurred by the JDK/JRE/JavaFX 11 releases, if not earlier).
JavaFX 11+
For JavaFX 11+, the information on feature differences above is completely irrelevant as the download page for JavaFX 11+ states:
As of JDK 11, the javafx.* modules are no longer included as part of the JDK. They are now distributed separately as a standalone, unbundled release of OpenJFX. They are available either as maven artifacts for use with Maven/Gradle or as a standalone SDK that includes jmod files for use with jlink.
So, there is no such thing as an Oracle-specific version of JavaFX for Java 11+ (as far as I know), for those versions, there is only the modules available from the open-source openjfx project (or other distributions that created their packaging based on the single openjfx source).
For further information on JavaFX 11+, see either the openjfx.io framework user site or the internal openjfx developer site.
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 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.
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.
Would I encounter any problems running Java programs and associated libraries compiled in Java version 1.6 and 1.7 (I'm compiling using 1.7 whereas some libraries are compiled using 1.6) and running the entire program in a 1.7 JRE?
As answered already you are mostly safe and most products and 3rd party libraries will simply work. However there do exist very rare cases where binary incompatibilities (ones where the class file compiled using older JDK will fail to run in the newer JVM) were introduced between JDK versions.
Official list of Oracle Java incompatibilities between versions:
in Java SE 9 since Java SE 8
in Java SE 8 since Java SE 7
in Java SE 7 since Java SE 6
in Java SE 6 since Java SE 5.0
in Java SE 5.0 since Java SE 1.4.2
Compatibility tool
Packaged with JDK 9, there is a tool called jdeprscan which will verify the compatibility, list no longer used APIs within your code and suggest alternatives(!). You can specify the target JDK version (works for JDK 9, 8, 7 and 6) and it will list incompatibilities specific to your target version.
Additional comment in case of libraries:
A reasonable rule of thumb is to use latest stable release version of library for the JRE version your software targets. Obviously you will find many exceptions from this rule, but in general stability of publicly available libraries usually increases with time.
Naturally API compatibility and versioning have to be considered when changing versions of dependencies.
Again most popular dependencies will have web pages where such information should be available.
If however you are using something a bit more obscure, you can discern which JRE were the classes within your dependency compiled for.
Here is a great answer on how to find out class version. You might need to unzip the JAR file first.
You would not encounter any problems - that's the magic of Java -it's backwards compatible.You can run almost all code from Java 1 on Java 8. There's no reason why Java 6 code won't run on a Java 8 Runtime.
What is interesting, is that for applications written in, let's say, Java 1.4, you even have speed increases when running them on later runtimes. This is because Java is constantly evolving, not just the language known as "Java", but also the JVM (Java virtual machine). I still have source code from more than 10 years ago that still work, as expected in the latest JVM.
If you want to target, let's say, a Java 5 VM, then you can do that with the Java 8 SDK tools. You can ultimately specify which target VM you wish to support, as long as you bear in mind that a version 5 VM might not support all the features a version 8 VM will.
I've just tested code I wrote in Java 5 against the new Java 8 runtime and everything works as expected, so, even though we have a more powerful language and runtime now, we can continue to use our investments of the past. Just that alone makes Java a great development choice for companies.