> 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.
> 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.
> 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.
> > 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...).
> 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.
The JAR is still there, though, in the package. Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one.
BTW, it is still perfectly acceptable to deliver an application as a JAR to developers who are expected to have a JDK and to know how to use it, and, of course, JARs are how all libraries are packaged.
> Depends on how much attack surface there is to that application and dependencies vs runtime
Ah, but that attack surface is smaller thanks to jlink. An application only distributes the runtime modules it actually needs.
> 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
For a small application that is local, i.e. not a server -- perhaps. If it is meant to be used developers, they can run it with their JDK, and if it is meant for end-users, then surely it shouldn't dictate how all other applications are run. The author of such an application would use some library that adds auto-update for the application (or just its runtime).
But I think that the belief that most attack vectors are due to the runtime rather than the application or its libraries, at least when it comes to servers, is less reality and more wishful thinking. The monolithic runtime in the JRE was both large and heavily studied, so there was a good stream of vulnerability reports, but that doesn't mean it was any less secure than your own application; it could have just felt that way because the application's security wasn't as well tested.
>The JAR is still there, though, in the package. Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one.
Easy, because I don't want to run the application under wine.
But it might not run unmodified under a new Java runtime, either. Codebases hacking into the JDK, using internal non-API classes, and making themselves tied to a specific version are common (even codebases that don't do that can become tied to a specific version or a range of versions, e.g. by generating or parsing bytecode). I hope they become less common when encapsulation is finally turned on in JDK 16, but even then applications can choose to selectively remove encapsulation -- for themselves and/or their dependencies -- use internals, and become tied to a specific version. Anyway, the JAR is still there, so you could try.
Fair enough, assuming it's easy to extract that eliminates my big concern. As a user of a less popular OS I worry about the jar-based flow becoming a second-class approach, but I do appreciate that having a first-class way of distributing "native" executables is important.
> Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one.
The point is that the jar<->jvm interface is a lot more stable than the jvm<->host system one. I suspect old JVM binaries would have linking issues (e.g. libc SONAME) or might not even be the right architecture to run on my current machines.
> Ah, but that attack surface is smaller thanks to jlink. An application only distributes the runtime modules it actually needs.
Sure, but things like low-level parsing are used by the application. It's not quite the same thing, but I maintain a couple of projects where approximately 100% of the security notifications I get are about vulnerabilities in Jackson, not because it's the majority of the library surface but because of what it's doing. Obviously Jackson isn't part of the JVM, but for an equivalent project that was using XML or CORBA I can easily imagine most of its attackable service being JVM code that the application really does use. There's also things like JMX which the application may well want to include even if it's not directly invoking it, but I remember as being a significant source of vulnerabilities.
> The author of such an application would use some library that adds auto-update for the application (or just its runtime).
Wasn't that the point of Java Web Start links? I usually favour leaving things up to libraries, but at the same time things need to be secure by default.
> But I think that the belief that most attack vectors are due to the runtime rather than the application or its libraries, at least when it comes to servers, is less reality and more wishful thinking. The monolithic runtime in the JRE was both large and heavily studied, so there was a good stream of vulnerability reports, but that doesn't mean it was any less secure than your own application; it could have just felt that way because the application's security wasn't as well tested.
I actually agree with that - most of those old applications probably only have security by obscurity. But still, there's a significant practical difference between "theoretically vulnerable" and "has a one-click prepackaged exploit". So encouraging every application to ship a static copy of the same chunk of well-known low-level code has a significant downsides - any vulnerability will become the equivalent of that zlib double free where essentially every MacOS program had to ship a new version.
> The point is that the jar<->jvm interface is a lot more stable than the jvm<->host system one.
This is complicated. The Java SE spec is very stable. But, unfortunately, many libraries and applications don't just program to the spec, and, rather, hack into the runtime (which is much more than just the JVM) and in that case their compatibility becomes much less stable than the VM<->OS one. This is changing soon with encapsulation (finally!) being switched on in 16, although applications will still have the option to selectively disable it, essentially saying, yes, we're giving up on portability but we know what we're doing.
> XML or CORBA I can easily imagine most of its attackable service being JVM code that the application really does use.
They're not in the JDK either, anymore. I don't think that the statement that most vulnerabilities will likely be in the runtime is true.
> Wasn't that the point of Java Web Start links? I usually favour leaving things up to libraries, but at the same time things need to be secure by default.
Yes, but it wasn't as good as we wanted. The problem is that Web Start still centralises the runtime and forces the user to interact with a third party. It's better for the application to choose how to manage its updates. This could, indeed, be done in a library, and I don't see why it would be any less secure than the JRE.
> So encouraging every application to ship a static copy of the same chunk of well-known low-level code has a significant downsides - any vulnerability will become the equivalent of that zlib double free where essentially every MacOS program had to ship a new version.
But it's not the same chunk. jlink customises the runtime to only contain the modules the application actually needs. This means that the JDK modules are like any other dependency, and there's no good reason to have a different update mechanism for them, which would also be controlled by a third party, especially since you'd need the application and dependency update anyway.
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.