Hacker News Reader

Comment by ok123456 | Hacker News Reader

> Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs.

Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application?

View on HN

> Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application?

You don't. Almost any Java program written ever will run on Java 18.

JavaFX isn't guaranteed to be in a JVM. You run into "deprecated" APIs that were removed. JVM options change, and that breaks how things are deployed. If the JVM were a stable target a site like http://whichjdk.com/ wouldn't be necessary.

This is just how things are. It's Java fanfiction to say this isn't the case, and necessitates having multiple JVMs installed.

Azul (not affiliated) provides JDKs with JavaFX bundled

https://www.azul.com/downloads/?version=java-17-lts&package=...

http://whichjdk.net seems to be a site that tells me not to use the Oracle JDK without a license? There's a listing of which releases were the first to include certain language features, but it seems to mainly be giving advice around JDK vendors, not JDK versions.

There are two kinds of backwards compatibility at play: BC for compiled artifacts (let's call this Java ABI compatibility) and BC for language APIs (Java API compatibility). I have run into issues trying to compile an application with one JDK version and then run it on another (specifically, I believe JVMs will generally not run artifacts compiled with a later JDK version), but API backwards incompatibility is really rare in Java.

I do recall having to do a bit of cleanup when a previous project moved from Java 8 to Java 11, since a ton of deprecated APIs were pruned in Java 9, but those APIs were published by the JDK authors as standalone JARs, so I could remediate by adding a maven dependency. JVM backwards compatibility isn't perfect, but it's a much more stable target than other languages I've worked in.

an odd one for me is JNLP - I have a motherboard with IPMI and they chose to do that through JNLP, which makes it an absolute pain in the ass to use the interface.

Unfortunately, FreePlane demands Java 8, I think.

I don't know, why do you?

There are occasionally breaking changes but most old jars out there will run fine in the latest runtime, so the answer to your question is going to depend on how squirrely your use case is.

Reply on news.ycombinator.com