Java 18 / JDK 18: General Availability

Re:Java 18 / JDK 18: General Availability by giaour on Tuesday March 22, 2022 @11:23AM (#30767195)

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.

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by paulmd on Tuesday March 22, 2022 @08:44PM (#30773496)

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

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by kaba0 on Wednesday March 23, 2022 @02:58AM (#30775746)

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

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by ok123456 on Tuesday March 22, 2022 @12:02PM (#30767718)

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

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by stevoski on Tuesday March 22, 2022 @12:33PM (#30768216)

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

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by ok123456 on Tuesday March 22, 2022 @12:38PM (#30768278)

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.

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by giaour on Tuesday March 22, 2022 @01:33PM (#30769008)

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.

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by _old_dude_ on Tuesday March 22, 2022 @12:46PM (#30768395)

Azul (not affiliated) provides JDKs with JavaFX bundled

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

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by paulmd on Tuesday March 22, 2022 @08:45PM (#30773504)

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.

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by Tomte on Tuesday March 22, 2022 @04:46PM (#30771307)

Unfortunately, FreePlane demands Java 8, I think.

[ Parent | on HN ]

Re:Java 18 / JDK 18: General Availability by NoSorryCannot on Tuesday March 22, 2022 @12:30PM (#30768166)

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.

[ Parent | on HN ]