Hacker News Reader

> Then what does the "java" command do exactly, if not run Java applications in some kind of runtime environment?

if you're using a normal desktop OS there's no system-wide "java" command (anymore (thankfully))

It's just a new iteration of the eternal software cycle :

10: "apps are shipped together with all their libraries / dependencies ! space is wasted / all apps must be upgraded when there is a security issue instead of one single dll ! let's share the runtime/DLLs/whatever which will solve all our issues !"

20: "oh no ! all apps are now dependent on a single runtime/DLL which {does not updates as fast as upstream | must be installed manually by the user who is clueless and will use the competition's software which JustWorks™ instead | causes DLL hell | must be patched to work with my software in a way that would break other software using the same runtime }, let's switch to static linking / bundling everything !"

GOTO 10

> if you're using a normal desktop OS there's no system-wide "java" command (anymore (thankfully))

Just about every Linux desktop, especially with LibreOffice installed, will have a system-wide java command. It is entirely normal and expected.

I have libreoffice and definitely not a single java binary in my path.

Not really more space if you do not use all symbols. More info here: https://drewdevault.com/dynlib

Try running that analysis for iOS apps against the dyld shared cache or for Android apps against the Android system frameworks.

More discussion as to why that treatment is not necessarily easy to interpret: https://news.ycombinator.com/item?id=23654353

> Honestly, this appears to destroy a fundamental promise that Java made when it was first released: Write once, run anywhere.

Correct. And I’m fine with that, it was a terrible idea right from the start for most use cases IMHO. If I never need to maintain a system wide Java again to run user applications I will be very happy.

The purpose of system runtimes (for Java, Python, whatever) is for running system components IMHO. User installed application dependencies beyond actual OS components are a user/vendor issue and I think the right way to handle that is on a per application basis.

I have this old KVM system I occasionally need to access. It is pretty old, so it's primary access method is a java browser plugin and those have been removed from every modern browsers.

Luckily, it still has that JNLP link, so I was able to get it to work. I am really glad that JNLP exists, and that they didn't use OS-specific bundle -- I am sure the latter would have been Windows only, and I don't run it.

>Correct. And I’m fine with that, it was a terrible idea right from the start for most use cases IMHO.

I completely disagree. Platform dependent Java is worse than useless the same way electron made Linux support worse.

Running a complicated Electron app under wine can be very difficult and yes you will have to run electron under wine one way or another because not every company provides linux builds of their electron apps.

What proportion of popular Electron apps do you think would have had first class Linux ports if Electron hadn't existed? I'm guessing not many.

I do sympathise, I fully realise Electron apps are sub-par in many ways compared to native apps, but to be brutally honest that's mainly a problem for platforms that would have had native apps otherwise. For linux that's generally not the case and it's either Electron or nothing.

Now ok, maybe nothing would be preferable in some ways because it might encourage native Linux competitors, but that's pretty unlikely to work out in practice. I think it's more likely that the availability of Electron versions of popular apps makes Linux a lot more viable as a user desktop, and that could promote better Linux support generally. For example once Outlook is an Electron app there might finally be an officially supported MS Outlook client for Linux. That's huge.

> Does "desktop" only include Mac OS? Neither on Linux nor Windows does the "app store model" rule. They exist, but are more like an obscure "you can also do it this way" method rather than the norm.

Even on mac OS, how much is it the norm? I think my only app store app on my work MBP is Slack.

For stuff that is available in the App Store, I prefer to get it there, even if it's more expensive than buying it directly from the vendor. It means that when I set up a new system I can go to my purchases tab and quickly re-install the 20-30 apps I have paid for that I only use every 1-2 months and they'll be ready the moment I need them, without having to dig through my email for license keys and download links

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

> The JAR is still there, though, in the package.

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.

Just to clarify, by

> They're not in the JDK either, anymore.

I meant CORBA and JAXB (see https://openjdk.java.net/jeps/320). JAXP is still in the JDK, and is part of the java.xml module.