9 ms·

> Java Web Start. This is the canonical way for desktop applications. Not anymore. Java Web Start was removed because the very concept of a JRE, a system-wide

by pron 6y ago

> Java Web Start. This is the canonical way for desktop applications. Not anymore. Java Web Start was removed because the very concept of a JRE, a system-wide runtime downloaded directly from Oracle and managed by the user or their IT department, no longer exists (despite some OpenJDK distributions offering something they call a JRE -- perhaps to maintain a sense of familiarity -- no one actually provides a JRE anymore, although I guess OpenWebStart is attempting to resurrect it). Like any other application, Java applications now only have two parties: the user and the application's vendor. It is the responsibility of the vendor to deliver the application along with any dependency, including a Java runtime. The vendor may choose to supply their own automatic update mechanism, for the application and the runtime, but users need not interact directly with the Java runtime anymore. Web Start, like Applets, was entirely predicated on the notion of the JRE. With the latter gone, the former is meaningless. Why was the JRE discontinued? 1. The software ecosystem now discourages system-wide third-party runtimes. On the desktop, the app store model rules; on the server, containers are popular -- both are much more friendly to an embedded runtime. 2. An embedded runtime with jlink gives the user a better experience by giving the software vendor full responsibility over their software and not requiring the user to deal with runtime components they don't, and need not, understand (although, admittedly, popular Java build tools currently lag in their support for jlink). In other words, the new way is better, but it does require getting used to. > While it can in theory work with any application, it shines with modularized applications. Not just in theory. jlink is the recommended practice for deploying any Java application, desktop or server, modular or not. While a modular application can help automate more steps of the packaging process (like not requiring running jdeps to find dependencies and automatically generating launcher scripts), jlink is not especially tied to modular applications. It is how all Java applications should be distributed (jpackage internally uses jlink). (I work at Oracle on OpenJDK)

chungy 6y ago
> Not anymore. Java Web Start was removed because the very concept of a JRE, a system-wide runtime downloaded directly from Oracle and managed by the user or their IT department, no longer exists (despite some OpenJDK distributions offering something they call a JRE -- perhaps to maintain a sense of familiarity -- no one actually provides a JRE anymore Then what does the "java" command do exactly, if not run Java applications in some kind of runtime environment? > It is the responsibility of the vendor to deliver the application along with any dependency, including a Java runtime. Honestly, this appears to destroy a fundamental promise that Java made when it was first released: Write once, run anywhere. And not just in the present, but for future systems as well. Are we now expected to have vendors provide 30 different downloads tailored for every operating system and architecture combination possible? And if that application needs to be run in 10, 20 years when the packages that were made can no longer run directly? It seems like a fairly dismal state of affairs, to me. > 1. The software ecosystem now discourages system-wide third-party runtimes. On the desktop, the app store model rules Does "desktop" only include Mac OS? Neither on Linux nor Windows does the "app store model" rule. They exist, but are more like an obscure "you can also do it this way" method rather than the norm. > on the server, containers are popular -- both are much more friendly to an embedded runtime. Containers are indeed popular, and maybe an embedded-JRE makes sense. I personally stick with installing whatever JRE package comes with Debian, myself; run them the traditional way. It certainly clears up a lot of uncertainty about the security of whatever Java runtime is being used, when a distribution (eg, Debian, Fedora, RHEL, etc) with a reputable security team takes care of that issue for me. The Java runtime gets updated, my servers restart, instant security buff. Trusting this to software vendors is just insane. > although, admittedly, popular Java build tools currently lag in their support for jlink This seems to show that developers haven't bitten the Oracle dream of vendored JREs. The "old" way of launching Java applications, both desktop and server, works perfectly fine to the present day, and few seem to be willing to alter that.
- Macha 6y ago
  > Does "desktop" only include Mac OS? Neither on Linux nor Windows does the "app store model" rule. They exist, but are more like an obscure "you can also do it this way" method rather than the norm. Even on mac OS, how much is it the norm? I think my only app store app on my work MBP is Slack.
  - xmodem 6y ago
    For stuff that is available in the App Store, I prefer to get it there, even if it's more expensive than buying it directly from the vendor. It means that when I set up a new system I can go to my purchases tab and quickly re-install the 20-30 apps I have paid for that I only use every 1-2 months and they'll be ready the moment I need them, without having to dig through my email for license keys and download links
- jcelerier 6y ago
  > Then what does the "java" command do exactly, if not run Java applications in some kind of runtime environment? if you're using a normal desktop OS there's no system-wide "java" command (anymore (thankfully)) It's just a new iteration of the eternal software cycle : 10: "apps are shipped together with all their libraries / dependencies ! space is wasted / all apps must be upgraded when there is a security issue instead of one single dll ! let's share the runtime/DLLs/whatever which will solve all our issues !" 20: "oh no ! all apps are now dependent on a single runtime/DLL which {does not updates as fast as upstream | must be installed manually by the user who is clueless and will use the competition's software which JustWorks™ instead | causes DLL hell | must be patched to work with my software in a way that would break other software using the same runtime }, let's switch to static linking / bundling everything !" GOTO 10
  - chungy 6y ago
    > if you're using a normal desktop OS there's no system-wide "java" command (anymore (thankfully)) Just about every Linux desktop, especially with LibreOffice installed, will have a system-wide java command. It is entirely normal and expected.
btown 6y ago
Other than size savings for the download and storage of potentially redundant things-formerly-known-as-the-JRE, were there performance benefits to having a shared JRE? Theoretically, a slow but Java-optimized system could cache (components of) the JRE in memory and make those pages available to novel JRE-based executables, much like a binary shared library [0]. Was this ever done in practice? I imagine it would have sped up Java Web Start startup times considerably - and mobile platforms as well, perhaps? [0]: see for instance https://unix.stackexchange.com/questions/458112/how-to-ensure-that-a-shared-library-will-have-its-memory-pages-shared-by-several https://unix.stackexchange.com/questions/458112/how-to-ensur...
- usrusr 6y ago
  On the desktop a clear no, on the server, back when you still had "apps per server" instead of "servers per app", who knows what might have been going on between the classloader hierarchies of your favorite EE platform and it's JVM.
- lmz 6y ago
  Sort of: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl...
- dti 6y ago
  There is a series of JEPs that add to OpenJDK a similar mechanism, class data sharing: - https://openjdk.java.net/jeps/310 https://openjdk.java.net/jeps/310 - https://openjdk.java.net/jeps/341 https://openjdk.java.net/jeps/341 - https://openjdk.java.net/jeps/350 https://openjdk.java.net/jeps/350
- pron 6y ago
  Hard to say, because many performance improvements were done after the JRE had been removed. There are reasons why a custom runtime can have better performance, though. jlink can place both a modular application and the runtime into a single image file that can be loaded quickly, and whose metadata can be cached efficiently.
fredgrott 6y ago
ahem I have a jre on ms windows recent Amazon distribution as the jdk doe sin fact embed a jre JRE is not discontinued still will be separate download for just a jre
- simonh 6y ago
  It has been officially discontinued for Oracle Java 11 and the OpenJDK. Some other vendors do offer a JRE and Amazon has their own variant of the OpenJDK called Corretto.
- pron 6y ago
  The JRE no longer exists. Some OpenJDK vendors ship a runtime that they call a JRE, but isn't.
  - deleted 6y ago
    [deleted]
  - rrdharan 6y ago
    I also don't understand this claim, given this text on oracle.com's Java page: https://www.oracle.com/java/technologies/javase-downloads.html https://www.oracle.com/java/technologies/javase-downloads.ht... Conceptually I always understood the difference between the JRE and the JDK to be that "the JRE lets you run Java" and the "the JDK lets you develop Java". To me this is the same as having libc vs. libc-dev or xlib vs xlib-dev or whatever installed. I don't really understand the branding distinctions but I would imagine there's still room for a smaller download that lets you run .JARs without including a javac and profiler and whatever else you might want in order to develop and debug them? [EDIT: Nevermind, I see that text all applied to Java 8 but not to Java 11 or Java 15. And implicitly as others have explained in this thread the reason being that there is no official use case for someone just wanting a JRE to run a .JAR they have; they should not just have a .JAR they should have obtained all of it together from the application vendor...] Which Java package do I need? Software Developers: JDK (Java SE Development Kit): For Java Developers. Includes a complete JRE plus tools for developing, debugging, and monitoring Java applications. Administrators running applications on a server: Server JRE (Server Java Runtime Environment): For deploying Java applications on servers. Includes tools for JVM monitoring and tools commonly required for server applications, but does not include browser integration (the Java plug-in), auto-update, nor an installer. Learn more End user running Java on a desktop: JRE: (Java Runtime Environment): Covers most end-users needs. Contains everything required to run Java applications on your system.
_old_dude_ 6y ago
> although, admittedly, popular Java build tools currently lag in their support for jlink Just an anecdote. We recently ship a CLI app companion to one of our WebApp that mostly dedup few dozen XLS files before uploading the content to the WebApp using jpackage. We are using this Maven plugin [1] to generate an exe, a rpm and a dmg. We spent far more time figuring out how to notarize an application on MacOs that using jpackage. [1] https://github.com/akman/jpackage-maven-plugin https://github.com/akman/jpackage-maven-plugin
- lmm 6y ago
  > We spent far more time figuring out how to notarize an application on MacOs that using jpackage. Does that say more about jpackage or about the MacOS notarization process?
dig1 6y ago
Linux distros still ship JRE and JDK separately (CentOS & Ubuntu, to name a few). There are a few reasons for this: the first one is that libraries will get shared [1] between multiple java processes. The second one, probably the most important, is that distro will keep JRE/JDK with security patches up to date. It will usually take a single package to be updated instead of (manually) updating every java app JVM out there. If you run multiple java apps on a single server, per-app JVM can be a problem. [1] Here I'm talking about core JVM libraries sharing (e.g., libjvm.so), done by Linux kernel.
- pron 6y ago
  No one ships a JRE (for versions after 8) because it no longer exists. Some distributors ship runtimes that they call a JRE, and the main (and pretty much only) reason for that is that some people are used to the old way and this gives them the illusion it still exists. It's a harmful practice, and such runtimes should not be used. Developers can use the runtime in the JDK, and end-users should use runtimes embedded in applications. The security story for embedded runtimes is both easier and safer, because each and every application needs to be updated anyway for vulnerabilities in the application itself or its dependencies, and embedded runtimes have a lower attack surface-area, as they include only modules the application actually needs.
  - saagarjha 6y ago
    Your argument is very similar to the one that people pushing static linking make. As such, “just update the application” has the exact same response: nobody is going to do this.
    - pron 6y ago
      I a not making an argument, I am explaining the situation, which is true regardless of what people think about it. I'm also not saying "just update the application." It's up to you how to maintain your software, but if you don't, the situation was just as bad with the JRE.
ternaryoperator 6y ago
That is the official Oracle line. However, the reality is that lots of organizations download JREs from AdoptOpenJDK [0] and go about their business as usual, without packaging their apps to fit Oracle's now-preferred model of delivery. [0] https://adoptopenjdk.net/installation.html#x64_win-jre https://adoptopenjdk.net/installation.html#x64_win-jre
- pron 6y ago
  No one downloads JREs from anywhere for versions later than 8 because they no longer exist. They might download runtimes that various vendors, like IBM (under the brand AdoptOpenJDK) call JREs, but aren't. Also, IBM's Adopt team is not involved with OpenJDK and are a bit confused about the project in general, but it is true that even more trustworthy JDK vendors distribute runtimes that they confusingly call JREs to provide a sense of continuity. Rest assured, though, those aren't JREs, and they do not support the old deployment models. Also, that "line" is from the actual developers who develop OpenJDK.
  - rrdharan 6y ago
    There might not be an official Oracle JRE(TM) anymore but JREs in the sense of independently distributed runtimes clearly still exist (and the acronym seems like a reasonable one). I can completely understand why Oracle might want to shift the Java world towards the jlink/embedded runtimes model. I can also completely understand why folks who've been shipping .JARs out to other folks who want to run them using runtimes obtained and distributed separately, which they call JREs, and have been doing so for the past 25 years would find this claim that "JREs no longer exist" as a concept, confusing at best and disingenuous at worst.
    - pron 6y ago
      > but there clearly still exist JREs. No, not really. There are runtimes that vendors call JREs, but they don't provide the same functionality as the JRE, only that of a Java runtime. Most of the code that's made the JRE the JRE has never been open-sourced and made part of OpenJDK. > this claim that the concept no longer exists, confusing at best and disingenuous at worst. It's not a claim. The JRE is gone. You can scour the OpenJDK source code for the JRE bits. It's just not there. You will find, however, the JRE's worthy successor, jlink. You will also find jpackage. Of course, I didn't mean that the concept is gone from people's minds (and it seems that OpenWebStart is attempting to manifest it in their software), but it isn't in OpenJDK. True, you can insist on asking your customers to install a Java runtime from some third party, and you can suggest that they share it among various applications, but that's not quite how the JRE used to work, it is not the recommended practice for OpenJDK, and it is confusing and disingenuous to claim that this obstinacy can conjure back the erstwhile JRE. It was great while it lasted, maybe it will come back in some other form in the future, but right now we have something different and better. In time, all Java developers will internalise this fact -- and come to enjoy it, I both hope and trust -- regardless of how long they've done things differently.
mcculley 6y ago
I love WebStart. I have been using it a long time. I use OpenWebStart and wish WebStart was supported in OpenJDK. I deploy a 738 byte .jnlp file to the desktops of my users and OpenWebStart ensures that they always have the latest version of our application. Yeah, I can use jlink/jpackage to give them a single executable blob. But with WebStart/OpenWebStart, it automatically checks to see if there is a newer version. I deploy to desktops that are not always connected to the Internet. It works great. They use the cached version of the JAR when disconnected. When connected, they are unobtrusively upgraded when a new version is available. jlink/jpackage is a step backwards for me.
- pron 6y ago
  It is not a step backward for anyone. The jlink model does not preclude auto-update of either the runtime or the application. It does preclude a JRE, i.e. a centralised "system" Java runtime that the user obtains from a third party. You can write a launcher that updates the runtime and your app that does what Web Start does, but for your applications. You do not and should not control which runtime is used for other applications from other vendors, and the user shouldn't need to go to a third-party that does, either.
  - mcculley 6y ago
    Yes, I can write a launcher that queries a URL and downloads the latest copy of my JAR if necessary. Fortunately for me, it already exists. It is called OpenWebStart. It is a shame that it is no longer in the JDK. Yes, it would be nice to narrow down the runtime, but that is not a requirement for me and others in my situation. I deploy multiple Java applications to desktops. I have been doing so since the late 90s. Requiring my users to use a current JRE/JDK is not at all problem. Ideally, I would have all of these apps share a common JVM so that they are not running multiple garbage collectors, but I realize this is a capability that most have simply discarded.
    - pron 6y ago
      I was not talking about something like Web Start and the JRE. The JRE was a centrally-managed software that determined the runtime for all Java applications. I don't think it's a good idea for one party to determine the runtime for applications written by others. It is better for your applications to manage their own runtime in a way that does not interfere with others. That is not what Web Start or OpenWebStart do; what they do is discouraged, even if you are used to it, because it makes global decisions over the user's environment that apply beyond the application itself. > Ideally, I would have all of these apps share a common JVM so that they are not running multiple garbage collectors, but I realize this is a capability that most have simply discarded. I'm not sure that one JVM doing more work would necessarily be better than multiple ones, but since you now control the runtime, you can do that if you like. Use a launcher that runs all of your applications JARs in one VM; since you control the applications, too, you could make sure that they are well isolated.
geokon 6y ago
From the outside it looks like an understandable shift away from desktop applications (the devs and money isn't there). I made an desktop app used Clojure + CLJFX and I got a ~25MB JAR. It then balloons to ~65MB jlinked packages. I ended up just releasing the JAR and telling people to install a Java 11 runtime (though I may revisit this at some point) I think what it boils down to is that b/c of Java's reflections you simply can't get rid of unused code/dependencies and things constantly bloat very fast. Small apps that should be 2MB are >20MB and are "un-emailable". On the server side this is a nonissue but to me it makes the ecosystem unsuitable for user-facing applications. There is a reason you don't see people making lil JVM desktop applications anymore. I love writing Clojure, writing the app with CLJFX was fantastic and fun but if I wanna make a quick app to crunch some data and make some plots I'm now very hesitant to reach for the JVM. I'm hoping with GraalVM the situation will change (b/c I don't think it supports reflections/RTTI and it can prune dead code/dependencies) but last I checked it didn't work with JavaFX. PS: I manually pruned the dependencies in `deps.edn` with `:exclusions` which helped a lot. Otherwise the app is in the ~200MB range.. But it's a manual process and tedious. The toolchains can't guarantee which code is unused. https://github.com/geokon-gh/corascope/blob/master/deps.edn https://github.com/geokon-gh/corascope/blob/master/deps.edn
- usrusr 6y ago
  As a former servlet API guy switched over to android I'm getting good results using proguard for pruning unused dependency parts from an ancient desktop app I'm maintaining on the side. Surely a hit on build times and on sanity as well whenever you use a library that relies on reflection internally, but it completely changed the way I deal with the convenience/download size tradeoff when deciding on dependencies.
  - geokon 6y ago
    Yeah, it's not a bad idea. I did try proguard at one point.. but it's such a baroque tool. It's likely something I did wrong, but I never managed to get proguard to remove anything properly. Either nothing was removed or it'd remove too much and kill the program. It's been a while, but something about it gave me the impression it didn't play with Clojure I wonder if you can then jlink the result
CC0EFB433E4C 6y ago
Luckily, Oracle cannot just delete concepts. JRE does not exist on Oracle management roadmaps, but the world can still use it. Zulu has a JRE (even JRE with JavaFX) which is so handy and has the added advantage of not being from Oracle. There is a reason tooling lags support for jlink: it's a mandated "solution" that nobody asked for. Just like JPMS, another great solution from Oracle in search of a problem which is still giving fruits 4 years later.
unnah 6y ago
> although, admittedly, popular Java build tools currently lag in their support for jlink That was definitely a problem. I had some bad experiences with maven-jlink-plugin last year, and seeing that it was stuck in 3.0.0-alpha1 since 2017 did not exactly inspire confidence. However, I just checked and the development of the plugin is now moving again: they released 3.0.0 in Novemeber and 3.1.0 in December, and the documentation has also been updated. So I guess it's time to try again...
captainmuon 6y ago
I was just going to point out that look, right there on Oracle's website, you can download the JRE. Even the "latest" version 8. Then I opened adoptOpenJDK in another tab and realize there is version 15 already?! Seems like a marketing fail - not the JRE is gone, but all the recent versions of Java without a JRE are. From the non-developers' perspective (end users and admins), "Java" is still very much a system component. The perception is basically: The only reason it is not preinstalled is due to some legal keruffle in the Windows XP era, you don't have to care about versions because it updates itself (annoyingly). It's sad that the idea of a JRE on every device has been given up.
- pron 6y ago
  I don't think it is sad at all, because the JRE was replaced by something better -- or, at least, more suitable to the current software landscape -- if perhaps still misunderstood: a software vendor decides which runtime to use, how to manage it and whether to share it among multiple applications rather than a third party controlling a component the end user doesn't understand. As to the marketing front, I would admit a failing on our part. Marketing has been centrally controlled by Oracle rather than by individual product divisions, which has made communication cumbersome, although that is now changing. This is perhaps a good time to emphasise that I'm not speaking on behalf of anyone in any official capacity, just on behalf of myself, as one of the hundreds of people working on OpenJDK at Oracle. In any event, that is the situation and people might need to change their perception. They don't have to like the new situation, but they do need to understand it, although so far it seems that once they understand it, they also like it.

by pron 6y ago

chungy 6y ago

> Not anymore. Java Web Start was removed because the very concept of a JRE, a system-wide runtime downloaded directly from Oracle and managed by the user or their IT department, no longer exists (despite some OpenJDK distributions offering something they call a JRE -- perhaps to maintain a sense of familiarity -- no one actually provides a JRE anymore Then what does the "java" command do exactly, if not run Java applications in some kind of runtime environment? > It is the responsibility of the vendor to deliver the application along with any dependency, including a Java runtime. Honestly, this appears to destroy a fundamental promise that Java made when it was first released: Write once, run anywhere. And not just in the present, but for future systems as well. Are we now expected to have vendors provide 30 different downloads tailored for every operating system and architecture combination possible? And if that application needs to be run in 10, 20 years when the packages that were made can no longer run directly? It seems like a fairly dismal state of affairs, to me. > 1. The software ecosystem now discourages system-wide third-party runtimes. On the desktop, the app store model rules Does "desktop" only include Mac OS? Neither on Linux nor Windows does the "app store model" rule. They exist, but are more like an obscure "you can also do it this way" method rather than the norm. > on the server, containers are popular -- both are much more friendly to an embedded runtime. Containers are indeed popular, and maybe an embedded-JRE makes sense. I personally stick with installing whatever JRE package comes with Debian, myself; run them the traditional way. It certainly clears up a lot of uncertainty about the security of whatever Java runtime is being used, when a distribution (eg, Debian, Fedora, RHEL, etc) with a reputable security team takes care of that issue for me. The Java runtime gets updated, my servers restart, instant security buff. Trusting this to software vendors is just insane. > although, admittedly, popular Java build tools currently lag in their support for jlink This seems to show that developers haven't bitten the Oracle dream of vendored JREs. The "old" way of launching Java applications, both desktop and server, works perfectly fine to the present day, and few seem to be willing to alter that.

Macha 6y ago
> Does "desktop" only include Mac OS? Neither on Linux nor Windows does the "app store model" rule. They exist, but are more like an obscure "you can also do it this way" method rather than the norm. Even on mac OS, how much is it the norm? I think my only app store app on my work MBP is Slack.
- xmodem 6y ago
  For stuff that is available in the App Store, I prefer to get it there, even if it's more expensive than buying it directly from the vendor. It means that when I set up a new system I can go to my purchases tab and quickly re-install the 20-30 apps I have paid for that I only use every 1-2 months and they'll be ready the moment I need them, without having to dig through my email for license keys and download links
jcelerier 6y ago
> Then what does the "java" command do exactly, if not run Java applications in some kind of runtime environment? if you're using a normal desktop OS there's no system-wide "java" command (anymore (thankfully)) It's just a new iteration of the eternal software cycle : 10: "apps are shipped together with all their libraries / dependencies ! space is wasted / all apps must be upgraded when there is a security issue instead of one single dll ! let's share the runtime/DLLs/whatever which will solve all our issues !" 20: "oh no ! all apps are now dependent on a single runtime/DLL which {does not updates as fast as upstream | must be installed manually by the user who is clueless and will use the competition's software which JustWorks™ instead | causes DLL hell | must be patched to work with my software in a way that would break other software using the same runtime }, let's switch to static linking / bundling everything !" GOTO 10
- chungy 6y ago
  > if you're using a normal desktop OS there's no system-wide "java" command (anymore (thankfully)) Just about every Linux desktop, especially with LibreOffice installed, will have a system-wide java command. It is entirely normal and expected.

btown 6y ago

Other than size savings for the download and storage of potentially redundant things-formerly-known-as-the-JRE, were there performance benefits to having a shared JRE? Theoretically, a slow but Java-optimized system could cache (components of) the JRE in memory and make those pages available to novel JRE-based executables, much like a binary shared library [0]. Was this ever done in practice? I imagine it would have sped up Java Web Start startup times considerably - and mobile platforms as well, perhaps? [0]: see for instance https://unix.stackexchange.com/questions/458112/how-to-ensure-that-a-shared-library-will-have-its-memory-pages-shared-by-several https://unix.stackexchange.com/questions/458112/how-to-ensur...

usrusr 6y ago
On the desktop a clear no, on the server, back when you still had "apps per server" instead of "servers per app", who knows what might have been going on between the classloader hierarchies of your favorite EE platform and it's JVM.
lmz 6y ago
Sort of: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl...
dti 6y ago
There is a series of JEPs that add to OpenJDK a similar mechanism, class data sharing: - https://openjdk.java.net/jeps/310 https://openjdk.java.net/jeps/310 - https://openjdk.java.net/jeps/341 https://openjdk.java.net/jeps/341 - https://openjdk.java.net/jeps/350 https://openjdk.java.net/jeps/350
pron 6y ago
Hard to say, because many performance improvements were done after the JRE had been removed. There are reasons why a custom runtime can have better performance, though. jlink can place both a modular application and the runtime into a single image file that can be loaded quickly, and whose metadata can be cached efficiently.

fredgrott 6y ago

ahem I have a jre on ms windows recent Amazon distribution as the jdk doe sin fact embed a jre JRE is not discontinued still will be separate download for just a jre

simonh 6y ago
It has been officially discontinued for Oracle Java 11 and the OpenJDK. Some other vendors do offer a JRE and Amazon has their own variant of the OpenJDK called Corretto.
pron 6y ago
The JRE no longer exists. Some OpenJDK vendors ship a runtime that they call a JRE, but isn't.
- deleted 6y ago
  [deleted]
- rrdharan 6y ago
  I also don't understand this claim, given this text on oracle.com's Java page: https://www.oracle.com/java/technologies/javase-downloads.html https://www.oracle.com/java/technologies/javase-downloads.ht... Conceptually I always understood the difference between the JRE and the JDK to be that "the JRE lets you run Java" and the "the JDK lets you develop Java". To me this is the same as having libc vs. libc-dev or xlib vs xlib-dev or whatever installed. I don't really understand the branding distinctions but I would imagine there's still room for a smaller download that lets you run .JARs without including a javac and profiler and whatever else you might want in order to develop and debug them? [EDIT: Nevermind, I see that text all applied to Java 8 but not to Java 11 or Java 15. And implicitly as others have explained in this thread the reason being that there is no official use case for someone just wanting a JRE to run a .JAR they have; they should not just have a .JAR they should have obtained all of it together from the application vendor...] Which Java package do I need? Software Developers: JDK (Java SE Development Kit): For Java Developers. Includes a complete JRE plus tools for developing, debugging, and monitoring Java applications. Administrators running applications on a server: Server JRE (Server Java Runtime Environment): For deploying Java applications on servers. Includes tools for JVM monitoring and tools commonly required for server applications, but does not include browser integration (the Java plug-in), auto-update, nor an installer. Learn more End user running Java on a desktop: JRE: (Java Runtime Environment): Covers most end-users needs. Contains everything required to run Java applications on your system.

_old_dude_ 6y ago

> although, admittedly, popular Java build tools currently lag in their support for jlink Just an anecdote. We recently ship a CLI app companion to one of our WebApp that mostly dedup few dozen XLS files before uploading the content to the WebApp using jpackage. We are using this Maven plugin [1] to generate an exe, a rpm and a dmg. We spent far more time figuring out how to notarize an application on MacOs that using jpackage. [1] https://github.com/akman/jpackage-maven-plugin https://github.com/akman/jpackage-maven-plugin

lmm 6y ago
> We spent far more time figuring out how to notarize an application on MacOs that using jpackage. Does that say more about jpackage or about the MacOS notarization process?

dig1 6y ago

Linux distros still ship JRE and JDK separately (CentOS & Ubuntu, to name a few). There are a few reasons for this: the first one is that libraries will get shared [1] between multiple java processes. The second one, probably the most important, is that distro will keep JRE/JDK with security patches up to date. It will usually take a single package to be updated instead of (manually) updating every java app JVM out there. If you run multiple java apps on a single server, per-app JVM can be a problem. [1] Here I'm talking about core JVM libraries sharing (e.g., libjvm.so), done by Linux kernel.

pron 6y ago
No one ships a JRE (for versions after 8) because it no longer exists. Some distributors ship runtimes that they call a JRE, and the main (and pretty much only) reason for that is that some people are used to the old way and this gives them the illusion it still exists. It's a harmful practice, and such runtimes should not be used. Developers can use the runtime in the JDK, and end-users should use runtimes embedded in applications. The security story for embedded runtimes is both easier and safer, because each and every application needs to be updated anyway for vulnerabilities in the application itself or its dependencies, and embedded runtimes have a lower attack surface-area, as they include only modules the application actually needs.
- saagarjha 6y ago
  Your argument is very similar to the one that people pushing static linking make. As such, “just update the application” has the exact same response: nobody is going to do this.
  - pron 6y ago
    I a not making an argument, I am explaining the situation, which is true regardless of what people think about it. I'm also not saying "just update the application." It's up to you how to maintain your software, but if you don't, the situation was just as bad with the JRE.

ternaryoperator 6y ago

That is the official Oracle line. However, the reality is that lots of organizations download JREs from AdoptOpenJDK [0] and go about their business as usual, without packaging their apps to fit Oracle's now-preferred model of delivery. [0] https://adoptopenjdk.net/installation.html#x64_win-jre https://adoptopenjdk.net/installation.html#x64_win-jre

pron 6y ago
No one downloads JREs from anywhere for versions later than 8 because they no longer exist. They might download runtimes that various vendors, like IBM (under the brand AdoptOpenJDK) call JREs, but aren't. Also, IBM's Adopt team is not involved with OpenJDK and are a bit confused about the project in general, but it is true that even more trustworthy JDK vendors distribute runtimes that they confusingly call JREs to provide a sense of continuity. Rest assured, though, those aren't JREs, and they do not support the old deployment models. Also, that "line" is from the actual developers who develop OpenJDK.
- rrdharan 6y ago
  There might not be an official Oracle JRE(TM) anymore but JREs in the sense of independently distributed runtimes clearly still exist (and the acronym seems like a reasonable one). I can completely understand why Oracle might want to shift the Java world towards the jlink/embedded runtimes model. I can also completely understand why folks who've been shipping .JARs out to other folks who want to run them using runtimes obtained and distributed separately, which they call JREs, and have been doing so for the past 25 years would find this claim that "JREs no longer exist" as a concept, confusing at best and disingenuous at worst.
  - pron 6y ago
    > but there clearly still exist JREs. No, not really. There are runtimes that vendors call JREs, but they don't provide the same functionality as the JRE, only that of a Java runtime. Most of the code that's made the JRE the JRE has never been open-sourced and made part of OpenJDK. > this claim that the concept no longer exists, confusing at best and disingenuous at worst. It's not a claim. The JRE is gone. You can scour the OpenJDK source code for the JRE bits. It's just not there. You will find, however, the JRE's worthy successor, jlink. You will also find jpackage. Of course, I didn't mean that the concept is gone from people's minds (and it seems that OpenWebStart is attempting to manifest it in their software), but it isn't in OpenJDK. True, you can insist on asking your customers to install a Java runtime from some third party, and you can suggest that they share it among various applications, but that's not quite how the JRE used to work, it is not the recommended practice for OpenJDK, and it is confusing and disingenuous to claim that this obstinacy can conjure back the erstwhile JRE. It was great while it lasted, maybe it will come back in some other form in the future, but right now we have something different and better. In time, all Java developers will internalise this fact -- and come to enjoy it, I both hope and trust -- regardless of how long they've done things differently.

mcculley 6y ago

I love WebStart. I have been using it a long time. I use OpenWebStart and wish WebStart was supported in OpenJDK. I deploy a 738 byte .jnlp file to the desktops of my users and OpenWebStart ensures that they always have the latest version of our application. Yeah, I can use jlink/jpackage to give them a single executable blob. But with WebStart/OpenWebStart, it automatically checks to see if there is a newer version. I deploy to desktops that are not always connected to the Internet. It works great. They use the cached version of the JAR when disconnected. When connected, they are unobtrusively upgraded when a new version is available. jlink/jpackage is a step backwards for me.

pron 6y ago
It is not a step backward for anyone. The jlink model does not preclude auto-update of either the runtime or the application. It does preclude a JRE, i.e. a centralised "system" Java runtime that the user obtains from a third party. You can write a launcher that updates the runtime and your app that does what Web Start does, but for your applications. You do not and should not control which runtime is used for other applications from other vendors, and the user shouldn't need to go to a third-party that does, either.
- mcculley 6y ago
  Yes, I can write a launcher that queries a URL and downloads the latest copy of my JAR if necessary. Fortunately for me, it already exists. It is called OpenWebStart. It is a shame that it is no longer in the JDK. Yes, it would be nice to narrow down the runtime, but that is not a requirement for me and others in my situation. I deploy multiple Java applications to desktops. I have been doing so since the late 90s. Requiring my users to use a current JRE/JDK is not at all problem. Ideally, I would have all of these apps share a common JVM so that they are not running multiple garbage collectors, but I realize this is a capability that most have simply discarded.
  - pron 6y ago
    I was not talking about something like Web Start and the JRE. The JRE was a centrally-managed software that determined the runtime for all Java applications. I don't think it's a good idea for one party to determine the runtime for applications written by others. It is better for your applications to manage their own runtime in a way that does not interfere with others. That is not what Web Start or OpenWebStart do; what they do is discouraged, even if you are used to it, because it makes global decisions over the user's environment that apply beyond the application itself. > Ideally, I would have all of these apps share a common JVM so that they are not running multiple garbage collectors, but I realize this is a capability that most have simply discarded. I'm not sure that one JVM doing more work would necessarily be better than multiple ones, but since you now control the runtime, you can do that if you like. Use a launcher that runs all of your applications JARs in one VM; since you control the applications, too, you could make sure that they are well isolated.

geokon 6y ago

From the outside it looks like an understandable shift away from desktop applications (the devs and money isn't there). I made an desktop app used Clojure + CLJFX and I got a ~25MB JAR. It then balloons to ~65MB jlinked packages. I ended up just releasing the JAR and telling people to install a Java 11 runtime (though I may revisit this at some point) I think what it boils down to is that b/c of Java's reflections you simply can't get rid of unused code/dependencies and things constantly bloat very fast. Small apps that should be 2MB are >20MB and are "un-emailable". On the server side this is a nonissue but to me it makes the ecosystem unsuitable for user-facing applications. There is a reason you don't see people making lil JVM desktop applications anymore. I love writing Clojure, writing the app with CLJFX was fantastic and fun but if I wanna make a quick app to crunch some data and make some plots I'm now very hesitant to reach for the JVM. I'm hoping with GraalVM the situation will change (b/c I don't think it supports reflections/RTTI and it can prune dead code/dependencies) but last I checked it didn't work with JavaFX. PS: I manually pruned the dependencies in `deps.edn` with `:exclusions` which helped a lot. Otherwise the app is in the ~200MB range.. But it's a manual process and tedious. The toolchains can't guarantee which code is unused. https://github.com/geokon-gh/corascope/blob/master/deps.edn https://github.com/geokon-gh/corascope/blob/master/deps.edn

usrusr 6y ago
As a former servlet API guy switched over to android I'm getting good results using proguard for pruning unused dependency parts from an ancient desktop app I'm maintaining on the side. Surely a hit on build times and on sanity as well whenever you use a library that relies on reflection internally, but it completely changed the way I deal with the convenience/download size tradeoff when deciding on dependencies.
- geokon 6y ago
  Yeah, it's not a bad idea. I did try proguard at one point.. but it's such a baroque tool. It's likely something I did wrong, but I never managed to get proguard to remove anything properly. Either nothing was removed or it'd remove too much and kill the program. It's been a while, but something about it gave me the impression it didn't play with Clojure I wonder if you can then jlink the result

CC0EFB433E4C 6y ago

Luckily, Oracle cannot just delete concepts. JRE does not exist on Oracle management roadmaps, but the world can still use it. Zulu has a JRE (even JRE with JavaFX) which is so handy and has the added advantage of not being from Oracle. There is a reason tooling lags support for jlink: it's a mandated "solution" that nobody asked for. Just like JPMS, another great solution from Oracle in search of a problem which is still giving fruits 4 years later.

unnah 6y ago

> although, admittedly, popular Java build tools currently lag in their support for jlink That was definitely a problem. I had some bad experiences with maven-jlink-plugin last year, and seeing that it was stuck in 3.0.0-alpha1 since 2017 did not exactly inspire confidence. However, I just checked and the development of the plugin is now moving again: they released 3.0.0 in Novemeber and 3.1.0 in December, and the documentation has also been updated. So I guess it's time to try again...

captainmuon 6y ago

I was just going to point out that look, right there on Oracle's website, you can download the JRE. Even the "latest" version 8. Then I opened adoptOpenJDK in another tab and realize there is version 15 already?! Seems like a marketing fail - not the JRE is gone, but all the recent versions of Java without a JRE are. From the non-developers' perspective (end users and admins), "Java" is still very much a system component. The perception is basically: The only reason it is not preinstalled is due to some legal keruffle in the Windows XP era, you don't have to care about versions because it updates itself (annoyingly). It's sad that the idea of a JRE on every device has been given up.

pron 6y ago
I don't think it is sad at all, because the JRE was replaced by something better -- or, at least, more suitable to the current software landscape -- if perhaps still misunderstood: a software vendor decides which runtime to use, how to manage it and whether to share it among multiple applications rather than a third party controlling a component the end user doesn't understand. As to the marketing front, I would admit a failing on our part. Marketing has been centrally controlled by Oracle rather than by individual product divisions, which has made communication cumbersome, although that is now changing. This is perhaps a good time to emphasise that I'm not speaking on behalf of anyone in any official capacity, just on behalf of myself, as one of the hundreds of people working on OpenJDK at Oracle. In any event, that is the situation and people might need to change their perception. They don't have to like the new situation, but they do need to understand it, although so far it seems that once they understand it, they also like it.