Once upon a time Java was pre-installed on Windows. And Java 8 is.not the best supported platform for consumers anymore.
So let's get one thing out of the way: the last version of Java that used a stand-alone JVM was Java 8. If it's tied to the OS, then the features we can use are tied to when the OS decides to update its included version. However, I think those pale in comparison to the fact that if Java is going to be a language that keeps getting updated and keeps getting better, we don't want the version tied to the OS. Microsoft may have wanted to promote C# and. Do you tell your users/customers not to run OS updates that might update Java and possibly break something? Do you forget about using new features in Java because some people are still on an older OS version which has an older Java? Do you make sure that everything runs well with all the different Java versions? It makes it a lot harder for programmers. Realistically, you don't really want your Java runtime to be dependent on your OS vendor. Even if you're running only one thing, you probably want to determine which version of Java you're using. You might want different Java versions for different programs. On Linux, what version of Java should everything run under? While Java maintains backwards compatibility a lot, it isn't perfect. I don't think Apple was trying to be malicious, it's just easy for engineers to get busy on other projects and updating the included Java wasn't something that people wanted to dedicate time to working on - there are far more interesting projects than moving over updates from Sun/Oracle. However, it was pretty annoying since it would get out of date as Apple had other priorities. As an example, Apple used to bundle a Java runtime with OS X. The latest JRE that's still maintained is for Java 8 (which is why 8 is the latest version on the consumer-oriented website, ), but it is outdated and not recommended for anyone who doesn't have to use it.īasically, because it doesn't work out well in real life. Some JDK vendors confusingly distribute a preconfigured Java runtime under the name "JRE", but those runtimes aren't really JREs. So the JRE can't be pre- or post-installed because the JRE simply no longer exists, nor does the concept of a global Java "environment". Applications are now meant to bundle their own custom, small Java runtime and take responsibility for updating it together with application updates, in line with current software distribution trends. With both Applets and Web Start discontinued and deployment moving to an app-store model on the desktop and to containers on the server, the JRE was discontinued in JDK 11.
The JRE, or the Java Runtime Environment, was a centralized, system-wide, auto-updating Java runtime, that could run Java Applets and Web Start applications, and was meant to be manged by consumers.
0 kommentar(er)
