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.
java java-9 java-10 java-11
edited Nov 25 '18 at 19:03
Naman
44.6k11102204
asked Nov 25 '18 at 18:55
AnkurAnkur
183
|
show 1 more comment
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.
java java-9 java-10 java-11
edited Nov 25 '18 at 19:03
Naman
44.6k11102204
asked Nov 25 '18 at 18:55
AnkurAnkur
183
Tried JDK on different platforms? that might help you undeerstand..
– Naman
Nov 25 '18 at 18:58
Do we really need jdk/ jre on client machines to run our java application when webstart and java plugins are getting removed in java 11?
– Ankur
Nov 25 '18 at 19:14
1
I meant correlating and not that it would be necessary to have them. Creating custom JRE usingjlinkis a resource you can browse to read further about the change and progress made by people on that aspect.
– Naman
Nov 25 '18 at 19:16
1
You've always needed platform-specific JREs/JVMs to run Java code. When embedding the JRE you need to package the correct one for the target platform.
– Slaw
Nov 25 '18 at 19:18
1
You can bundle your application with a jre. You don’t have to. Look at how Eclipse and Netbeans offer bundled versions for certain common platforms while still offering a generic Java version with the highest portability (for more than a decade). It’s a matter of convenience. Of course, it’s in the hands of the application vendors to still offer a pure Java version, just like it always was in their hands, to write a truly platform independent software, i.e. not to rely on system specific artifacts or behavior in the code.
– Holger
Nov 26 '18 at 13:24
|
show 1 more comment
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.
java java-9 java-10 java-11
edited Nov 25 '18 at 19:03
Naman
44.6k11102204
asked Nov 25 '18 at 18:55
AnkurAnkur
183
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.
java java-9 java-10 java-11
java java-9 java-10 java-11
edited Nov 25 '18 at 19:03
Naman
44.6k11102204
asked Nov 25 '18 at 18:55
AnkurAnkur
183
edited Nov 25 '18 at 19:03
Naman
44.6k11102204
asked Nov 25 '18 at 18:55
AnkurAnkur
183
edited Nov 25 '18 at 19:03
Naman
44.6k11102204
edited Nov 25 '18 at 19:03
Naman
44.6k11102204
edited Nov 25 '18 at 19:03
Naman
44.6k11102204
44.6k11102204
asked Nov 25 '18 at 18:55
AnkurAnkur
183
asked Nov 25 '18 at 18:55
AnkurAnkur
183
asked Nov 25 '18 at 18:55
AnkurAnkur
183
183
Tried JDK on different platforms? that might help you undeerstand..
– Naman
Nov 25 '18 at 18:58
Do we really need jdk/ jre on client machines to run our java application when webstart and java plugins are getting removed in java 11?
– Ankur
Nov 25 '18 at 19:14
1
I meant correlating and not that it would be necessary to have them. Creating custom JRE usingjlinkis a resource you can browse to read further about the change and progress made by people on that aspect.
– Naman
Nov 25 '18 at 19:16
1
You've always needed platform-specific JREs/JVMs to run Java code. When embedding the JRE you need to package the correct one for the target platform.
– Slaw
Nov 25 '18 at 19:18
1
You can bundle your application with a jre. You don’t have to. Look at how Eclipse and Netbeans offer bundled versions for certain common platforms while still offering a generic Java version with the highest portability (for more than a decade). It’s a matter of convenience. Of course, it’s in the hands of the application vendors to still offer a pure Java version, just like it always was in their hands, to write a truly platform independent software, i.e. not to rely on system specific artifacts or behavior in the code.
– Holger
Nov 26 '18 at 13:24
|
show 1 more comment
Tried JDK on different platforms? that might help you undeerstand..
– Naman
Nov 25 '18 at 18:58
Do we really need jdk/ jre on client machines to run our java application when webstart and java plugins are getting removed in java 11?
– Ankur
Nov 25 '18 at 19:14
1
I meant correlating and not that it would be necessary to have them. Creating custom JRE usingjlinkis a resource you can browse to read further about the change and progress made by people on that aspect.
– Naman
Nov 25 '18 at 19:16
1
You've always needed platform-specific JREs/JVMs to run Java code. When embedding the JRE you need to package the correct one for the target platform.
– Slaw
Nov 25 '18 at 19:18
1
You can bundle your application with a jre. You don’t have to. Look at how Eclipse and Netbeans offer bundled versions for certain common platforms while still offering a generic Java version with the highest portability (for more than a decade). It’s a matter of convenience. Of course, it’s in the hands of the application vendors to still offer a pure Java version, just like it always was in their hands, to write a truly platform independent software, i.e. not to rely on system specific artifacts or behavior in the code.
– Holger
Nov 26 '18 at 13:24
Tried JDK on different platforms? that might help you undeerstand..
– Naman
Nov 25 '18 at 18:58
Tried JDK on different platforms? that might help you undeerstand..
– Naman
Nov 25 '18 at 18:58
Do we really need jdk/ jre on client machines to run our java application when webstart and java plugins are getting removed in java 11?
– Ankur
Nov 25 '18 at 19:14
Do we really need jdk/ jre on client machines to run our java application when webstart and java plugins are getting removed in java 11?
– Ankur
Nov 25 '18 at 19:14
1
1
I meant correlating and not that it would be necessary to have them. Creating custom JRE using
jlink is a resource you can browse to read further about the change and progress made by people on that aspect.– Naman
Nov 25 '18 at 19:16
I meant correlating and not that it would be necessary to have them. Creating custom JRE using
jlink is a resource you can browse to read further about the change and progress made by people on that aspect.– Naman
Nov 25 '18 at 19:16
1
1
You've always needed platform-specific JREs/JVMs to run Java code. When embedding the JRE you need to package the correct one for the target platform.
– Slaw
Nov 25 '18 at 19:18
You've always needed platform-specific JREs/JVMs to run Java code. When embedding the JRE you need to package the correct one for the target platform.
– Slaw
Nov 25 '18 at 19:18
1
1
You can bundle your application with a jre. You don’t have to. Look at how Eclipse and Netbeans offer bundled versions for certain common platforms while still offering a generic Java version with the highest portability (for more than a decade). It’s a matter of convenience. Of course, it’s in the hands of the application vendors to still offer a pure Java version, just like it always was in their hands, to write a truly platform independent software, i.e. not to rely on system specific artifacts or behavior in the code.
– Holger
Nov 26 '18 at 13:24
You can bundle your application with a jre. You don’t have to. Look at how Eclipse and Netbeans offer bundled versions for certain common platforms while still offering a generic Java version with the highest portability (for more than a decade). It’s a matter of convenience. Of course, it’s in the hands of the application vendors to still offer a pure Java version, just like it always was in their hands, to write a truly platform independent software, i.e. not to rely on system specific artifacts or behavior in the code.
– Holger
Nov 26 '18 at 13:24
|
show 1 more comment
4 Answers
4
active
oldest
votes
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.
answered Nov 25 '18 at 19:39
Basil BourqueBasil Bourque
115k29393556
add a comment |
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.
answered Nov 25 '18 at 20:45
Michael BerryMichael Berry
44k16115169
add a comment |
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.
answered Nov 25 '18 at 20:19
Rene KnopRene Knop
1,3633823
Well my question was not about module system instead it was about Platform Independence. I know how module system works. 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. Also to create these images now developer would need to compile the same program on 3 different machine, so that we are able to ship it.
– Ankur
Nov 26 '18 at 14:17
add a comment |
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.
answered Nov 25 '18 at 21:24
Peter LawreyPeter Lawrey
447k56574977
4
see the link dzone.com/articles/…
– Ankur
Nov 26 '18 at 15:11
@Ankur a good link with more details on this.
– Peter Lawrey
Nov 26 '18 at 16:53
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53470804%2fis-java-9-and-above-still-platform-independent-or-not-after-this-module-system-h%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Nov 25 '18 at 19:39
Basil BourqueBasil Bourque
115k29393556
add a comment |
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.
answered Nov 25 '18 at 19:39
Basil BourqueBasil Bourque
115k29393556
add a comment |
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.
answered Nov 25 '18 at 19:39
Basil BourqueBasil Bourque
115k29393556
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.
answered Nov 25 '18 at 19:39
Basil BourqueBasil Bourque
115k29393556
edited Jan 22 at 23:34
answered Nov 25 '18 at 19:39
Basil BourqueBasil Bourque
115k29393556
answered Nov 25 '18 at 19:39
Basil BourqueBasil Bourque
115k29393556
answered Nov 25 '18 at 19:39
Basil BourqueBasil Bourque
115k29393556
115k29393556
add a comment |
add a comment |
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.
answered Nov 25 '18 at 20:45
Michael BerryMichael Berry
44k16115169
add a comment |
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.
answered Nov 25 '18 at 20:45
Michael BerryMichael Berry
44k16115169
add a comment |
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.
answered Nov 25 '18 at 20:45
Michael BerryMichael Berry
44k16115169
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.
answered Nov 25 '18 at 20:45
Michael BerryMichael Berry
44k16115169
answered Nov 25 '18 at 20:45
Michael BerryMichael Berry
44k16115169
answered Nov 25 '18 at 20:45
Michael BerryMichael Berry
44k16115169
answered Nov 25 '18 at 20:45
Michael BerryMichael Berry
44k16115169
44k16115169
add a comment |
add a comment |
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.
answered Nov 25 '18 at 20:19
Rene KnopRene Knop
1,3633823
Well my question was not about module system instead it was about Platform Independence. I know how module system works. 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. Also to create these images now developer would need to compile the same program on 3 different machine, so that we are able to ship it.
– Ankur
Nov 26 '18 at 14:17
add a comment |
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.
answered Nov 25 '18 at 20:19
Rene KnopRene Knop
1,3633823
Well my question was not about module system instead it was about Platform Independence. I know how module system works. 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. Also to create these images now developer would need to compile the same program on 3 different machine, so that we are able to ship it.
– Ankur
Nov 26 '18 at 14:17
add a comment |
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.
answered Nov 25 '18 at 20:19
Rene KnopRene Knop
1,3633823
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.
answered Nov 25 '18 at 20:19
Rene KnopRene Knop
1,3633823
edited Nov 28 '18 at 21:51
answered Nov 25 '18 at 20:19
Rene KnopRene Knop
1,3633823
answered Nov 25 '18 at 20:19
Rene KnopRene Knop
1,3633823
answered Nov 25 '18 at 20:19
Rene KnopRene Knop
1,3633823
1,3633823
Well my question was not about module system instead it was about Platform Independence. I know how module system works. 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. Also to create these images now developer would need to compile the same program on 3 different machine, so that we are able to ship it.
– Ankur
Nov 26 '18 at 14:17
add a comment |
Well my question was not about module system instead it was about Platform Independence. I know how module system works. 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. Also to create these images now developer would need to compile the same program on 3 different machine, so that we are able to ship it.
– Ankur
Nov 26 '18 at 14:17
Well my question was not about module system instead it was about Platform Independence. I know how module system works. 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. Also to create these images now developer would need to compile the same program on 3 different machine, so that we are able to ship it.
– Ankur
Nov 26 '18 at 14:17
Well my question was not about module system instead it was about Platform Independence. I know how module system works. 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. Also to create these images now developer would need to compile the same program on 3 different machine, so that we are able to ship it.
– Ankur
Nov 26 '18 at 14:17
add a comment |
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.
answered Nov 25 '18 at 21:24
Peter LawreyPeter Lawrey
447k56574977
4
see the link dzone.com/articles/…
– Ankur
Nov 26 '18 at 15:11
@Ankur a good link with more details on this.
– Peter Lawrey
Nov 26 '18 at 16:53
add a comment |
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.
answered Nov 25 '18 at 21:24
Peter LawreyPeter Lawrey
447k56574977
4
see the link dzone.com/articles/…
– Ankur
Nov 26 '18 at 15:11
@Ankur a good link with more details on this.
– Peter Lawrey
Nov 26 '18 at 16:53
add a comment |
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.
answered Nov 25 '18 at 21:24
Peter LawreyPeter Lawrey
447k56574977
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.
answered Nov 25 '18 at 21:24
Peter LawreyPeter Lawrey
447k56574977
edited Nov 26 '18 at 16:50
answered Nov 25 '18 at 21:24
Peter LawreyPeter Lawrey
447k56574977
answered Nov 25 '18 at 21:24
Peter LawreyPeter Lawrey
447k56574977
answered Nov 25 '18 at 21:24
Peter LawreyPeter Lawrey
447k56574977
447k56574977
4
see the link dzone.com/articles/…
– Ankur
Nov 26 '18 at 15:11
@Ankur a good link with more details on this.
– Peter Lawrey
Nov 26 '18 at 16:53
add a comment |
4
see the link dzone.com/articles/…
– Ankur
Nov 26 '18 at 15:11
@Ankur a good link with more details on this.
– Peter Lawrey
Nov 26 '18 at 16:53
4
4
see the link dzone.com/articles/…
– Ankur
Nov 26 '18 at 15:11
see the link dzone.com/articles/…
– Ankur
Nov 26 '18 at 15:11
@Ankur a good link with more details on this.
– Peter Lawrey
Nov 26 '18 at 16:53
@Ankur a good link with more details on this.
– Peter Lawrey
Nov 26 '18 at 16:53
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53470804%2fis-java-9-and-above-still-platform-independent-or-not-after-this-module-system-h%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Tried JDK on different platforms? that might help you undeerstand..
– Naman
Nov 25 '18 at 18:58
Do we really need jdk/ jre on client machines to run our java application when webstart and java plugins are getting removed in java 11?
– Ankur
Nov 25 '18 at 19:14
1
I meant correlating and not that it would be necessary to have them. Creating custom JRE using
jlinkis a resource you can browse to read further about the change and progress made by people on that aspect.– Naman
Nov 25 '18 at 19:16
1
You've always needed platform-specific JREs/JVMs to run Java code. When embedding the JRE you need to package the correct one for the target platform.
– Slaw
Nov 25 '18 at 19:18
1
You can bundle your application with a jre. You don’t have to. Look at how Eclipse and Netbeans offer bundled versions for certain common platforms while still offering a generic Java version with the highest portability (for more than a decade). It’s a matter of convenience. Of course, it’s in the hands of the application vendors to still offer a pure Java version, just like it always was in their hands, to write a truly platform independent software, i.e. not to rely on system specific artifacts or behavior in the code.
– Holger
Nov 26 '18 at 13:24