4 ms·

> 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

by 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.

lmm 6y ago
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.
- pron 6y ago
  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.
  - usrusr 6y ago
    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".
    - pron 6y ago
      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).
      - rrdharan 6y ago
        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. Are you familiar with Debian? What would you call this? https://packages.debian.org/buster/default-jre https://packages.debian.org/buster/default-jre 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.
solidsnack9000 6y ago
"...they don't provide the same functionality as the JRE..." What functionality are you referring to, exactly?
- pron 6y ago
  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.
speciwesle 6y ago
How was GIF pronounced again? Calling a Java runtime environment a Java Runtime Environment sounds fair to me. >but that's not quite how the JRE used to work You can help by expanding the how
- pron 6y ago
  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.

by pron 6y ago

lmm 6y ago

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.

pron 6y ago
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.
- usrusr 6y ago
  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".
  - pron 6y ago
    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).
    - rrdharan 6y ago
      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. Are you familiar with Debian? What would you call this? https://packages.debian.org/buster/default-jre https://packages.debian.org/buster/default-jre 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.

solidsnack9000 6y ago

"...they don't provide the same functionality as the JRE..." What functionality are you referring to, exactly?

pron 6y ago
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.

speciwesle 6y ago

How was GIF pronounced again? Calling a Java runtime environment a Java Runtime Environment sounds fair to me. >but that's not quite how the JRE used to work You can help by expanding the how

pron 6y ago
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.