Java 21 / JDK 21 Reaches GA With Virtual Threads, Generational ZGC

[phoronix]

Phoronix: Java 21 / JDK 21 Reaches GA With Virtual Threads, Generational ZGC

Java 21 and the JDK 21 release under a general availability (GA) status occurred a short time ago as the newest major update to the Java programming language...

https://www.phoronix.com/news/Java-21-Released

[stormcrow]

This would be more relevant if over half the Java programs I use weren't still stuck on Java 8. One only recently updated to work with Java 17. The rest are more agnostic because they're not as complex as the others or they have larger numbers of contributors (and nearly unlimited resources behind one) allowing them to migrate faster, or a combination of both. It's a pain for developers, and nearly as much for their users having to keep multiple mutually-incompatible versions of Java around.

[bug77]

This would be more relevant if over half the Java programs I use weren't still stuck on Java 8. One only recently updated to work with Java 17. The rest are more agnostic because they're not as complex as the others or they have larger numbers of contributors (and nearly unlimited resources behind one) allowing them to migrate faster, or a combination of both. It's a pain for developers, and nearly as much for their users having to keep multiple mutually-incompatible versions of Java around.

Please stop this "mutually-incompatible versions" nonsense. There was exactly one major "removal" of APIs from Java and it was related to internal classes that were never meant to be used outside of the JDK (they always came with a disclaimer): https://openjdk.org/jeps/403
Everything else was a few method calls here and there, related to ancient stuff: https://docs.oracle.com/en/java/java...oved-apis.html

Whatever programs are still stuck on Java8 are stuck because they depend on ancient libraries that aren't updated (probably full of CVEs by now) or because their developers don't care anymore.
Irl I have only found one instance where it was hard to move off Java 8 and that was because it ran on embedded (I know, I know) and further JDKs regressed in performance too much. Not because anything was incompatible.

[stormcrow]

Please stop this "mutually-incompatible versions" nonsense. There was exactly one major "removal" of APIs from Java and it was related to internal classes that were never meant to be used outside of the JDK (they always came with a disclaimer): https://openjdk.org/jeps/403
Everything else was a few method class here and there, related to ancient stuff: https://docs.oracle.com/en/java/java...oved-apis.html

Whatever programs are still stuck on Java8 are stuck because they depend on ancient libraries that aren't updated (probably full of CVEs by now) or because their developers don't care anymore.
Irl I have only found one instance where it was hard to move off Java 8 and that was because it ran on embedded (I know, I know) and further JDKs regressed in performance too much. Not because anything was incompatible.

If you're willing to come "fix" the API problem, you can dictate what "mutually incompatible" means, but for all practical purposes some Java 8 based programs and its younger siblings aren't compatible. Otherwise, the end result is the same and the rest is irrelevant.

[bachchain]

Consider the classic Hello, World! program that is often used as the first program for Java students:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

There is too much clutter here — too much code, too many concepts, too many constructs — for what the program does.

It only took them 28 years to notice Java's fundamental flaw.

[archkde]

Please stop this "mutually-incompatible versions" nonsense. There was exactly one major "removal" of APIs from Java and it was related to internal classes that were never meant to be used outside of the JDK (they always came with a disclaimer): https://openjdk.org/jeps/403
Everything else was a few method class here and there, related to ancient stuff: https://docs.oracle.com/en/java/java...oved-apis.html

The other big issue, as I remember, was toolchain incompatibilities introduced by the modularized standard library.

[jayv]

This would be more relevant if over half the Java programs I use weren't still stuck on Java 8.

Have you tried to read the manual and find the command line args to very likely make your ancient unsupported apps run on a modern JVM? .

[jayv]

The other big issue, as I remember, was toolchain incompatibilities introduced by the modularized standard library.

It was a big issue.... and was quickly solved a long time ago, Java v9 was released more than 6 year ago and all major tools and libraries were compatible at the time... but let's keep spreading FUD that's more exciting.

[cynic]

It only took them 28 years to notice Java's fundamental flaw.

if all you have to do is write a string of text, before questionimg how many lines of Java are required you'd better question if you actually need a sophisticated piece of technology as a computer with an entire OS running on it.

maybe a piece of paper and a pencil would suffice.

[Ironmask]

This would be more relevant if over half the Java programs I use weren't still stuck on Java 8. One only recently updated to work with Java 17. The rest are more agnostic because they're not as complex as the others or they have larger numbers of contributors (and nearly unlimited resources behind one) allowing them to migrate faster, or a combination of both. It's a pain for developers, and nearly as much for their users having to keep multiple mutually-incompatible versions of Java around.

My exact thoughts before coming into this thread.
Every time I hear about a JVM update I'm always excited to hear what new tech goes into it - and then become disappointed when I realize that nobody is going to use it.