4 ms·
> if not run Java applications in some kind of runtime environment? Well, it is a runtime, but it isn't some global environment. Just a process. It doesn't ev
by pron 6y ago
> if not run Java applications in some kind of runtime environment?
Well, it is a runtime, but it isn't some global environment. Just a process. It doesn't even have a concept of installation. If you have multiple runtimes, then runtime1/bin/java ... and runtime2/bin/java ... would run the program using each image's own configuration and librarary.
> Honestly, this appears to destroy a fundamental promise that Java made when it was first released: Write once, run anywhere.
I fail to see how. You write once (and you even build once; you just package multiple times) and run anywhere.
> Are we now expected to have vendors provide 30 different downloads tailored for every operating system and architecture combination possible?
The answer to your question is that that's up to the developer. If you like, you can write an updater and a launcher and package it for every architecture once, and then have it download your applications as JARs. But, if you choose not to, just remember that jlink "cross links" and the only platform-specific part of the process is the packaging.
> And if that application needs to be run in 10, 20 years when the packages that were made can no longer run directly?
Then repackage the JARs. It's as before, only more in line with how people want software delivered these days. When preferences change, the deployment process might change again.
> and maybe an embedded-JRE makes sense
It's not a JRE, just a runtime.
> I personally stick with installing whatever JRE package comes with Debian, myself; run them the traditional way.
I think you mean the JDK, and sure, developers can use the runtime in the JDK to run JARs. The new deployment process is for non-developers, who shouldn't have the JDK.
> Trusting this to software vendors is just insane.
Oh no, quite the opposite, in fact. Security vulnerabilities can and do exist in each and every component: the application, the libraries it uses, their transitive dependencies and the runtime. It's better for security for the end user to have one source in charge.
> 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.
Well, it's gone, though, and the new way is so much better that those that have used it don't look back. It's great! It's more secure and a better experience all around. Sure, there are those who are afraid of change, change takes time, and it's perfectly fine. They'll switch to the new, better model, each in their own pace.
- lmm 6y ago> I fail to see how. You write once (and you even build once; you just package multiple times) and run anywhere. "Packaging" seems to be much more part of writing than it is part of running. In particular it seems like something that has to be done by the original maintainer, rather than something that any user can do for themselves even if the original maintainer and source have disappeared, which was one of the great strengths of Java - I can download a jar that was produced by someone who disappeared 20 years ago, and have a reasonable level of confidence that it will work unmodified on my machine today. > Oh no, quite the opposite, in fact. Security vulnerabilities can and do exist in each and every component: the application, the libraries it uses, their transitive dependencies and the runtime. It's better for security for the end user to have one source in charge. For cases where the application vendor is a big competent organisation, maybe. For cases where the application vendor is a hobbyist who could never have maintained the dependencies or runtime on their own, not really - a lot of the time they're simply not up to providing security updates for the whole transitive closure of their dependencies on a timely schedule.
- pron 6y ago> I can download a jar that was produced by someone who disappeared 20 years ago, and have a reasonable level of confidence that it will work unmodified on my machine today. You can still do that without a JRE; in fact, it is easier because there is no central notion of a single "Java version." > a lot of the time they're simply not up to providing security updates for the whole transitive closure of their dependencies on a timely schedule. Right, but the JRE didn't do that, either. A well-updated runtime with an ill-maintained application and dependencies is no better than an ill-maintained application, dependencies and runtime, especially if the runtime is has a lower attack surface area.
- lmm 6y ago> > I can download a jar that was produced by someone who disappeared 20 years ago, and have a reasonable level of confidence that it will work unmodified on my machine today. > You can still do that without a JRE; in fact, it is easier because there is no central notion of a single "Java version." But if the jlink-based approach you're advocating had been the norm 20 years ago, that jar file would never have been published; I'd be able to download packages of that application that worked for the systems of 20 years ago, but it would be a lot harder to run those on my current machine. > Right, but the JRE didn't do that, either. A well-updated runtime with an ill-maintained application and dependencies is no better than an ill-maintained application, dependencies and runtime, especially if the runtime is has a lower attack surface area. Depends on how much attack surface there is to that application and dependencies vs runtime, remembering that the Java standard library actually covers a lot of the basics. Often for a small application the Java runtime (including standard library) is actually the only part of the whole stack that's doing high-risk things (opening network sockets, parsing low-level data formats, implementing stateful protocol negotiations...).