4 ms·

Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. (Though the 8->9 t

by giaour 5y ago

Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. (Though the 8->9 transition was pretty rough for some.) Compiled Java artifacts are usually portable across OSes and CPU architectures, so your build pipeline can be pretty simple even if your infrastructure is not. JVM performance is generally fine, and the language prevents you from introducing whole classes of memory safety bugs. You can still shoot yourself in the foot with native (JNI) extensions, but the decent performance of the JVM makes developers use JNI far less frequently than, say, Python or Ruby devs reach for compiled libraries. JVM byte code decompilation is fairly trivial, so tools for the security scanning of artifacts are cheaper and more fully featured than similar tools for scanning machine code.

ok123456 5y ago
> 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?
- NoSorryCannot 5y ago
  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.
- stevoski 5y ago
  > 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.
  - ok123456 5y ago
    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/ 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.
    - _old_dude_ 5y ago
      Azul (not affiliated) provides JDKs with JavaFX bundled https://www.azul.com/downloads/?version=java-17-lts&package=jre-fx https://www.azul.com/downloads/?version=java-17-lts&package=...
    - giaour 5y ago
      http://whichjdk.net 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.
    - paulmd 5y ago
      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.
  - Tomte 5y ago
    Unfortunately, FreePlane demands Java 8, I think.
paulmd 5y ago
> Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. this has been the case in the past, but Java is gritting its teeth and making some breaking changes in the JDK11/16/18 era. libraries that mess with the unsafe/internal namespaces are the most prominent example - there are a ton of legacy libraries that are going to break from that change unless updated - but there's also a big push for modules and for classes to encapsulate themselves more strongly.
- kaba0 5y ago
  Which is essential for the longevity of a platform. You can’t further develop the JVM if you are bogged down by code depending on the internals. Encapsulation by modules is hugely important, and if we are honest, anything that depended on internals were prone to bugs anyways. Sure it sucks, but they will update sooner or later

by giaour 5y ago

ok123456 5y ago

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

NoSorryCannot 5y ago
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.
stevoski 5y ago
> 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.
- ok123456 5y ago
  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/ 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.
  - _old_dude_ 5y ago
    Azul (not affiliated) provides JDKs with JavaFX bundled https://www.azul.com/downloads/?version=java-17-lts&package=jre-fx https://www.azul.com/downloads/?version=java-17-lts&package=...
  - giaour 5y ago
    http://whichjdk.net 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.
  - paulmd 5y ago
    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.
- Tomte 5y ago
  Unfortunately, FreePlane demands Java 8, I think.

paulmd 5y ago

> Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. this has been the case in the past, but Java is gritting its teeth and making some breaking changes in the JDK11/16/18 era. libraries that mess with the unsafe/internal namespaces are the most prominent example - there are a ton of legacy libraries that are going to break from that change unless updated - but there's also a big push for modules and for classes to encapsulate themselves more strongly.

kaba0 5y ago
Which is essential for the longevity of a platform. You can’t further develop the JVM if you are bogged down by code depending on the internals. Encapsulation by modules is hugely important, and if we are honest, anything that depended on internals were prone to bugs anyways. Sure it sucks, but they will update sooner or later