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.
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.
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.
If it's a runtime environment for Java, it's a JRE in the sense that the term is usually used and understood. Language is a tool for communication; if you want "JRE" to mean something other than the common-sense interpretation of that acronym, the burden for making a clear distinction between your technical definition and the common-sense everyday use of that term is on you.
It's a runtime, not a runtime environment. The common meaning of a JRE is some system-wide Java environment, that the user obtains from a third-party (Oracle) and installs on their machine, with a system-wide "current" Java version. That no longer exists.
It is true that if everyone understood the difference between a JRE and any other Java runtime, yet chose to call them all "JRE" and expect the meaning to be understood from context, insistence over proper terminology would have merely been pedantic, but that's not the situation. Discontinuing the JRE in favour of custom runtimes was a big change, and one that people still don't fully understand.
And yet users obtain runtime environments for programs distributed as java bytecode and install them on their machine, system wide, all the time. Claiming the opposite isn't pedantic, it's something far beyond pedantic. For this usage pattern, the only thing that has disappeared is the distinction between full JDK download and the slightly trimmed down "runtime only" that had been causing all kinds of avoidable trouble immortalized by the Google search term "tools.jar".
I am not "claiming" anything. I am informing developers that as of versions beyond 8, we've discontinued the JRE and it no longer exists, and what you've described does not replicate its functionality.
> For this usage pattern, the only thing that has disappeared is the distinction between full JDK download and the slightly trimmed down "runtime only"
That's incorrect. What's disappeared is any notion of a system-wide Java environment managed by a third party, and that's what the JRE was.
The JDK is now also not a system-wide environment in any way. While the usage you've described of asking end-users to "install" a JDK (i.e. placing it on your hard drive; the JDK also no longer has any installation beyond that) and pointing some system-wide configuration at it is discouraged for non-developer, and while people might still do it despite the JDK providing much better alternative, it still does not work like the JRE, and not only because the JDK is larger (BTW, speaking of the JDK size, as of JDK 9, the JDK contains the entire core libraries not just once but twice, once as jmod files used by jlink to create runtime images, and once again in its own runtime image).
It seems you're struggling with the distinction between what Oracle calls the JRE, and what large or at least significant-to-HN swaths of industry seem to be calling it.
You seem very fixated on the desktop aspects of this that have been removed, such as JWS and the Control Panel. Neither of those are relevant to Linux server distributions.
Until common Linux distributions no longer have an option to globally install a "default" environment that provides a Java Runtime via /usr/bin/java globally, it is nonsensical to talk about the JRE "not existing" regardless of what the OpenJDK team has decided for the future.
I guess you're asking whether now that the JRE no longer exists [1] and some people choose to distribute other kinds of Java runtimes and call them "JRE" (different runtimes named JRE from different vendors are not the same), is that an acceptable use of the term? I don't really care as long as people understand, one, the difference between the JRE and any other Java runtime, whatever they choose to call it -- I will use the OpenJDK terminology, though -- and that two, OpenJDK discourages the use of runtimes managed by third parties on non-developer systems and such users shouldn't be encouraged to install one; a runtime shared by multiple applications and managed by their vendor is perfectly fine (as is deploying an application intended for developers as a JAR and relying on them to use their JDK's runtime to run it).
BTW, the JRE was desktop software. For the server, there was a "Server JRE" (https://www.oracle.com/uk/java/technologies/javase-server-jr...) which is, indeed, much more similar than the (desktop) JRE to the various server runtimes various vendors now call "JRE".
[1]: Technically, OpenJDK has never had a JRE because the JRE has never been open-sourced, but now that Oracle has open-sourced the entire JDK and discontinued the JRE entirely, there is no more a popular JDK that isn't an OpenJDK build (although there are not-so-popular JDKs that aren't OpenJDK, like OpenJ9), and so the popular Java implementation no longer has a JRE.
The JRE was mostly about the plugin (Applets) and Web Start. Those two are gone. Then its main features were the auto-update and the control panel. These are also gone.
It's not an environment, just a runtime. The difference is that the JRE was some system-wide global environment, whose version was selected by the user and controlled with a control-panel. Now the runtime is just an executable picked by the application.
The dominant old deployment model has been and still is building a fat jar (or a folder of jars with a start script containing a comically long classpath) and declaring which minimum version of a java installation it requires. This might not have received much attention at Oracle and likely not even in later Sun days, but that's because it worked so well that it didn't need any.
Also, that "line" is from the actual developers who develop OpenJDK.