6 ms·

It's a pity that system wide JREs are not a thing anymore. I understand that it was difficult to get an updated JRE on the system in the early 2000s, but nowada

It's a pity that system wide JREs are not a thing anymore. I understand that it was difficult to get an updated JRE on the system in the early 2000s, but nowadays almost every computer is online - certainly one where you are currently downloading an application on - and automatic updates are commonplace. You used to be able to just double click on a .jar, and that was a Java application. And it would be trivial engineering-wise to include a little shim that downloads the JRE if neccessary, or the OS could do it itself. And why stop with Java? Why not have the OS detect the most common cases of "hey you are about to open <thing>" (where thing is a Python / Java / .NET app, or a document you can't open yet) "click here to install the needed bits and pieces from a trusted source, it will take 300 MB and 3 minutes". I think this is a case of perfect is the enemy of the good. This is a relatively simple addition that would make computers much nicer IMO.

erik_seaberg 4y ago
Yeah, I have trouble believing a private runtime image per app isn't going to add up to more than one complete runtime image provided by the system package manager or shared Docker layer.
- kaba0 4y ago
  But unfortunately the state would be having `n` complete runtime images for different versions. This is not a Java problem, Java just followed suit, and seemingly the preferred way of delivering executables is bundling everything.
  - erik_seaberg 4y ago
    Yeah, that’s not my preference, and I haven’t seen a team do it.
toyg 4y ago
We already have that, it's called a package manager. The concept has a number of problems (multiple runtime versions for multiple programs, who pays for and controls the repository, etc etc).
- luxoramonrising 4y ago
  > multiple runtime versions for multiple programs For Java, the latest one. Current latest java still runs 20 year old jars. > who pays for and controls the repository The OS distributor.
  - adra 4y ago
    "For Java, the latest one. Current latest java still runs 20 year old jars." Not necessarily anymore. Many of the standard JVM features were removed in 11+ instances, so things like _some_ of the JVMs JMX APIs were removed for one reason or other. I'm not saying the removals weren't justified, simply clarifying that not all java applications written N years ago are still entirely supported.
  - toyg 4y ago
    > Current latest java still runs 20 year old jars. Dude, I've been using Java since 1.2. Sure, all versions will try to "run" anything, but they'll do that with all sorts of slight differences and incompatibilities in behaviour - which make it effectively impractical for any serious program to run on anything but a small subset of tried and tested versions. > The OS distributor Careful what you wish for. Do you really want to hand Microsoft the power to decide which runtimes are allowed to run on Windows...?
- captainmuon 4y ago
  I don't know, my package manager doesn't let me download an application without runtime - say QBittorrent without Qt or Deluge without Gtk and Python - double click on an icon, and then say "It looks like you are trying to <strike>write a letter</strike> run an app that needs a library" and then proceeds to fetch it... from my package manager. I mean, 80/20 principle. You would only have to write code for the dozen or so runtimes, and then add metadata for a few hundred or so popular apps. Totally in reach for a volunteer community (like many distros, or stuff like PortableApps) and especially for a companies like Canonical or Microsoft. And then when it is going, people would add metadata to their apps themselves, and we would no longer have to ship the runtimes together with the apps. Think of the metadata it like a 21st century shebang line. Not `#!/usr/bin/env python`, but `#"§% require python>3.9 and gtk-stack>4.0` or `require java-xxx`.
chriswarbo 4y ago
Sounds like https://0install.net https://0install.net which has been around for a while. Personally I prefer to avoid 'installing' anything: if something's written in Java, its launcher should reference some specific java binary; if something's written in Python, it should reference some specific python3 binary; etc. For example, my job is mostly writing Scala and building it with Maven; yet I have neither installed system-wide. Instead, they're just dependencies of the build script (along with Bash, etc.).

erik_seaberg 4y ago

Yeah, I have trouble believing a private runtime image per app isn't going to add up to more than one complete runtime image provided by the system package manager or shared Docker layer.

kaba0 4y ago
But unfortunately the state would be having `n` complete runtime images for different versions. This is not a Java problem, Java just followed suit, and seemingly the preferred way of delivering executables is bundling everything.
- erik_seaberg 4y ago
  Yeah, that’s not my preference, and I haven’t seen a team do it.

toyg 4y ago

We already have that, it's called a package manager. The concept has a number of problems (multiple runtime versions for multiple programs, who pays for and controls the repository, etc etc).

luxoramonrising 4y ago
> multiple runtime versions for multiple programs For Java, the latest one. Current latest java still runs 20 year old jars. > who pays for and controls the repository The OS distributor.
- adra 4y ago
  "For Java, the latest one. Current latest java still runs 20 year old jars." Not necessarily anymore. Many of the standard JVM features were removed in 11+ instances, so things like _some_ of the JVMs JMX APIs were removed for one reason or other. I'm not saying the removals weren't justified, simply clarifying that not all java applications written N years ago are still entirely supported.
- toyg 4y ago
  > Current latest java still runs 20 year old jars. Dude, I've been using Java since 1.2. Sure, all versions will try to "run" anything, but they'll do that with all sorts of slight differences and incompatibilities in behaviour - which make it effectively impractical for any serious program to run on anything but a small subset of tried and tested versions. > The OS distributor Careful what you wish for. Do you really want to hand Microsoft the power to decide which runtimes are allowed to run on Windows...?
captainmuon 4y ago
I don't know, my package manager doesn't let me download an application without runtime - say QBittorrent without Qt or Deluge without Gtk and Python - double click on an icon, and then say "It looks like you are trying to <strike>write a letter</strike> run an app that needs a library" and then proceeds to fetch it... from my package manager. I mean, 80/20 principle. You would only have to write code for the dozen or so runtimes, and then add metadata for a few hundred or so popular apps. Totally in reach for a volunteer community (like many distros, or stuff like PortableApps) and especially for a companies like Canonical or Microsoft. And then when it is going, people would add metadata to their apps themselves, and we would no longer have to ship the runtimes together with the apps. Think of the metadata it like a 21st century shebang line. Not `#!/usr/bin/env python`, but `#"§% require python>3.9 and gtk-stack>4.0` or `require java-xxx`.

chriswarbo 4y ago

Sounds like https://0install.net https://0install.net which has been around for a while. Personally I prefer to avoid 'installing' anything: if something's written in Java, its launcher should reference some specific java binary; if something's written in Python, it should reference some specific python3 binary; etc. For example, my job is mostly writing Scala and building it with Maven; yet I have neither installed system-wide. Instead, they're just dependencies of the build script (along with Bash, etc.).