We Keep Coding

If JVM<JRE<JDK why if I install the last version of JDK, a specific JRE installation is also required to make games work?

Is JRE contained in JDK installation or I'm wrong? Why do I have to install specifically the JRE in order to play games based on Java, for example Minecraft?

If JVM<JRE<JDK
This isn't true, but JRE < JDK is more or less true.
a specific JRE installation is also required to make games work?
Actually, JREs are dead; java8 is now over 5 years old and is the last version where a JRE is the intended distribution model. The JRE model works as follows:
The developer installs a JDK and builds their java application with it.
The developer ships a bunch of jar files to the end user.
The end user will download a JRE from e.g. oracle and installs it. That user and oracle work together to do the maintenance on this (keep it updated for example to close a security leak in the JRE); developer is no party in this at all.
The reason the JRE exists at all is because it can be simpler and smaller, and its download and maintenance can be streamlined for end users and not developers.
This is also why a game would want a JRE: A JDK doesn't, as a rule, ship with managed security updates because a JDK is targeted at developers who are assumed to know better and keep it up to date. (They don't, of course, but that's another issue).
This model is obsolete. The new model is:
The developer installs a JDK and builds their java application with it.
They use jlink or other installer creation tools to produce an installer which is then shipped to the end user. jlink can make a custom cut-down version of the JDK without developer tools and with only those parts of the java libraries that are needed. Even smaller than a JRE, in other words.
End user installs. They have no arrangement with oracle or any other 'JRE provider' and do not need a JRE on their system; even if one is there, it won't be used. Distribution of any updates (including security updates) to the cut-down java runtime being used are entirely the responsibility of the app maker.
That latter model is in practice how most 'runs on the desktop' java software was distributed anyway: asking users to install a JRE is an annoyance, and is also unreliable: What if your app doesn't run on jre8 because you wrote it for jre6 and something updated in 8 breaks your app, but the end user updates their jre?
Now that latter model is the official model, which makes your question mostly moot.
Minecraft presumably needs to update its deployment.
NB: Some companies, such as Azul, still distribute something they call 'jre11'. These distributions are meant for shops that cannot easily transition away from the old distribution model of 'user maintains a JRE, developer distributes just jar files', but do want to use new java features. Oracle doesn't distribute these, and this distribution model is no less obsoleted. 'obsolete' doesn't mean 'impossible', just 'not recommended / you need to find some time to move away from it / definitely do not do this for new projects'.

Is JRE contained in JDK installation?
Pre Java 11 it was but post Java 11 it isn't
Why do I have to install specifically the JRE in order to play games
based on Java, for example Minecraft?
Looks like from Java 11 on things have changed: https://stackoverflow.com/a/53733414/1098361

How to migrate java application form oracle jdk to openjdk?

we have one java application which is deployed in jboss application server and using java 1.8.0_202 version, now we want to change it to openjdk.
how can i change?
is there any code changes required?
please help me complete steps to be performed?
Thanks in advance..

No changes required to your codebase when switching between implementations of Java 8. Java is defined by a set of specifications along with JSRs and JEPs. Any implementation that complies with those specs will run your JBoss app server. Your existing WAR or EAR file will run as-is with no changes needed.
Understand that the OpenJDK project provides an implementation of Java as source code. The OpenJDK project does not provide binary builds nor installers. For builds and installers, you must locate a vendor. You have a choice of several, some free-of-cost and some that require a fee.
Here is a flowchart I made to help you choose a vendor.
This chart is aimed at Java 11, but many of these vendors also supply Java 8. Some, such as Azul Systems, have even back-ported features to Java 8 such as Flight Recorder.

Is JavaFX part of the public API?

I am working with code that involves using the JavaFX platform and I encountered the following error from Eclipse while trying to import the Application class from the javafx.application package:
Access restriction: The type 'Application' is not API (restriction on
required library rt.jar)
I encountered the above error when trying to import classes from the javafx.application, javafx.scene, and javafx.stage packages.
Thanks to this answer, I know so far that the problem arises from access restrictions placed by Eclipse by default to prevent the accidental use of classes which it thinks are not part of the public API. Is this the case for JavaFX? Also, I'm also not sure I'm completely clear on what it means for a package or class to be in the public API.

Thank to responses from #Slaw and #Benjamin to #Florian's answer, I think I can now provide an answer to my question:
JavaFX 2.2 and later releases are fully integrated with the Java SE 7 Runtime Environment (JRE) and the Java Development Kit (JDK). However, JavaFX is no longer a part of the standard JDK, as of Java SE 11. This is probably why Eclipse is worried and requires explicit access rules for the library.
Also, the comments have helped to clarify that this does not mean that the stability and future reliability of JavaFX is completely uncertain. JavaFX, as of now, is stable and is being developed as OpenJFX which is part of the OpenJDK project (a free, open-source implementation of the Java SE). The latest release is JavaFX 13.
In summary, JavaFX has a "public" API such as the javafx.* packages and a "private" API such as the com.sun.javafx.* packages. However, the implication of the current state of JavaFX is that as a library, it will have to be pulled in like any other external dependency since it is not bundled with the standard JDK/JRE.

To make it short, JavaFX is not in the "public" Java API.
The Java API contains the most common tools a developer needs, for example collections, network, different parsers, etc...
Therefor JavaFX is not in the public Java API.
If you want to see which tools are included you can check out this link https://docs.oracle.com/javase/7/docs/api/ .

is java 9 and above still platform independent or not after this module system has been introduced?

I am not able to understand that after module system is introduced in our java language. Is java9 and above still platform independent or not ? I am asking this question because I have read that now every application will have its own jre inside it. So, how will this single jre run on all OS, like windows, Linux, or Mac OS.

You are conflating two different changes recently made to the Java platform:
Retiring of Java Web Start & Applet technologies
Modularization
Retiring desktop-technologies
Recently Oracle announced the phasing out of the Java Web Start technologies, in addition to the already-deprecated Applet technology. See item JDK-8184998 in Java 9 Release Notes:
Java Deployment Technologies are deprecated and will be removed in a future release
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.
End-users will no longer be encouraged to install a JDK or JRE on their computer.
For more details, see the eight-page 2018-03 white paper from Oracle, Java Client Roadmap Update.
So then, how are developers of Swing or JavaFX apps to deliver their software to the end-user?
Oracle suggests packaging up your app along with a JVM & JRE for delivery as a single launch-ready applications on that appears on the client to be just another app alongside the native apps. Such “double-clickable” app-packaging has been commonly done on the Mac since the beginning of Java. But what was once an obscure art on other host environments (Linux, BSD, Windows, etc.) will now be the norm, as it is on macOS.
In yesteryear, bundling a Java runtime with your app required jumping over some licensing hurdles. The legalities have eased with arrival of the open-source OpenJDK project, and possibly with other implementations†.
You will need to prepare different releases of your app for each hosting environment. While your Java code runs independently of the host OS, the JVM is built of native code to interact with one specific kind of host. So you will need to build a Linux release with a Linux JVM, a macOS release with a macOS JVM, and so on. While that may seem like a downer, the upside is that you no longer need to worry about users having the wrong JVM version installed, or no JVM at all. Now the JVM’s presence and version are under your control. Your end-users and customers will no longer need to be aware that your app is Java-based.
Modularization
That need for app-packaging has nothing to do with the modularization of Java. As I said, it has been done for decades on the Mac.
What modularization brings to the party is that the JVM/JRE you bundle into your delivered app can be customized to contain only the Java Modules actually utilized by your particular app. This results in a smaller size, so your finished app is smaller, downloads are faster, less storage is used, and your app may load faster.
The open-source jlink “Java Linker” tool helps with the packaging work, so you can assemble and optimize a set of modules and their dependencies (only the ones actually called by your app) into a custom run-time image. This modular run-time image format is defined in JEP 220.
† On a related note, you may want to read the white paper Java Is Still Free to understand how and where to obtain a Java implementation for your app, and what support may or may not be offered in either free-of-cost or paid releases.
By the way, you may find helpful this Answer on a related Question, with a flowchart of choosing various sources of a Java implementation.

Is java9 and above still platform independent or not ?
Yes. It's as platform independent as it ever was. The module system has nothing to do with platform independence.
now every application will have its own jre inside it.
It doesn't have to, but it's more and more recommended as time goes on since fewer people have Java installed separately on their systems. This used to be a given, but that number has been declining for the last decade or so, and now (outside of Java developers) pretty much no-one has a standalone JRE installed.
how will this single jre run on all OS
It won't. You will bundle a separate JRE for each platform you want to distribute for. But JRE's for all platforms are still freely available, and the same Java code will still run on a JRE for any platform.

The module system doesn't influence the OS independency of java in general. Java applications that make use of the module system need to be run in a JRE. This can be either an OS specific pre-installed JRE as usual or a tailored runtime image (application embedded JRE) created with JLink.
The module systems main purpose is to provide you a managed way to split your application into different logical modules. E.g. into different .jar files that can be loaded at runtime - no matter on which operating system.
In summary, you have the following options:
Make sure that your client has the right JRE pre-installed. This could be dangerous, because (normally) you are not in control of his updating behavior.
Ship your application together with an official JRE.
Tailor your own, application and OS specific runtime image using JLink. Ship it bundled with your application.
But, suppose I do not know what OS my client would be running so how
the server will decide what image he should give to him. i.e., a Mac
Image, a Linux Image or a Windows exe.
You have to know the target OS and deliver the right runtime image.

While Java 9 makes it easier to ship a JRE which is more compact and specific to the needs of an individual application, you are not required to do so. If you were already planning to ship a JRE with your application it can be smaller with Java 9 than earlier versions.
It doesn't mean you have to ship a JRE, an application which wasn't shipped with a JRE is unlikely to start shipping with one now, and in fact Java 11 only ships as a JDK.
From this link on Java 9 features;
JLink allows you to create custom runtime images that only consist of your application modules and those JRE modules that your application requires. The result is likely a smaller runtime image, which uses fewer resources than a default JRE.

How do I upgrade to jlink (JDK 9+) from Java Web Start (JDK 8) for an auto-updating application?

Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:
Native code on Windows, Mac and Linux
Modularization of the code (although Proguard does this as well)
The use of new, supported technology.
The problem: I can't find the canonical Java solution to auto-update with jlink.
One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?
For the purposes of this question the following are out of scope:
Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.

In May 2019 commented to watch the OpenWebStart project.
Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.
The OpenWebStart Technical Details page states:
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.
The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features1 and their implementation status is provided in the feature table.
1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.
Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.

I had a similar problem in a past project. We needed to migrate from Webstart to another technology.
The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.
But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.
Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.
Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.

Do you use maven?
I've resolved my similar problem with maven (I need to update an EAR).
My main app (the ear package) has a pom.xml with listed the dependencies and repositories.
The dependencies have the <version> tag with a range (documentation) as in this example
<version>[1.0.0,)</version>
That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)
In the repository section I added my personal repository.
Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.
You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way
PRO
This schema can be used in a lot of different projects.
CONTRO
You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);
You must write code in different jars and add them like dependencies in the main archive.
You must change JAR version each time and publish on the repository (this could be a good practice)