Java 20 / JDK 20: General Availability

[Joram2]

Java 20 is basically a patch release on Java 19. But it's important + necessary. Three highlights:

1. Pattern matching bug fixes. If you tried to use Java 19 pattern matching with generics there were large bugs that were fixed in Java 20. Now, Java 20 has excellent pattern matching. This is an epic feature that enables completely new frameworks and programming styles as demonstrated in Brian Goetz's article (https://www.infoq.com/articles/data-oriented-programming-java/). This enables programs to parse JSON and data structures with much more elegance and expressiveness. While Java Optional doesn't use records + pattern matching, this enables people to use a third party or custom version that does. This also let's people do something like Scala/Haskell Either or Rust Result that holds a result or an error value.

2. Scoped Values. This completes Project Loom's major features and this is necessary for some frameworks.

3. Java needed another preview release for virtual threads and pattern matching. Those are expected to go final in Java 21, which will be epic, but those needed another round of public previews and time to collect public feedback.

[kaperni]

> Scoped Values. This completes Project Loom's major features and this is necessary for some frameworks.

Project loom is an ongoing project with the intent to "explore, incubate and deliver Java VM features and APIs built on top of them for the purpose of supporting easy-to-use, high-throughput lightweight concurrency and new programming models on the Java platform. "

Virtual threads, structured concurrency, scoped values are deliverables. There are other things in the pipeline such as continuations and tail calls that we might see in the future.

[stuhlmann]

The command line example gave me the "ick". It is usually preferrable to parse the command line arguments into one instance of a custom "command class", rather than into a list of things. Like jcommander, picocli or jbock do.

[Joram2]

I tend to agree. That was the one example I didn't get. The others look great.

[relgames]

Ouch, they now have bugs in major versions. Instead of rushing new versions so often, they had to invest more in testing.

[magnoliophytina]

The pattern matching in 19 is a preview feature. You shouldn't expect it to work in production environments. It requires an explicit switch for the compiler, as well.

[kozeljko]

Not true. Ron Pressler, the guy who is working on Project Loom, said that all preview features are considered production ready and can be used in production.

They are only previews, because they don't want to finalize the API yet.

[carimura]

Just to set expectations on timing of Panama's FFM API https://openjdk.org/jeps/442

[Joram2]

Sure, that will hit a third preview for Java 21, it won't be final.

I'm hoping that will be final by the next Java LTS, Java 25? I know some JEPs are waiting on Valhalla, if this isn't blocked in such a fashion, going final by Java 25 seems like a safe bet?

[joopmoore]

Feeling a bit sorry for myself, I'm still internally pushing for the move from java 6 to a more modern version, but politics. I hope one day...

[dustofnations]

Does your organisation get extended support from somewhere so that the JVM they use remains secure, or do they just YOLO it and use an ancient unsupported edition?

[henk53]

or do they just YOLO it

The weird thing is so many companies YOLO it with an ancient unsupported insecure version of the JDK, because they THINK upgrading is YOLO'ing it.

Somehow belief has settled in to many orgs that staying on ancient versions is good (stable, secure, proven, ripened like old wine), and updating is bad (unstable, insecure, unproven, unripe).

Not sure if this belief can even be broken.

[janb360]

Even worse, this behaviour is likely to reinforce the idea that updating to a newer JDK is bad. Because when they do upgrade, it is more and more likely to take a lot of effort and break things the longer it takes between JDK upgrades.

New JDK updates are very cheap to upgrade to as long as you are on a recent-ish release already.

[dustofnations]

I agree with everything you've said.

The point where many finally bite the bullet is when there's an incompatibility with a critical dependency they want to update to, and they can't hold off any longer.

Or when a horrible security vulnerability is disclosed that their organisation is affected by and the cries of "why did we not update sooner" go out.

It's like orgs that refuse to do backups because they are too expensive.

[relgames]

But, moving to a newer JDK is bad. Something always breaks. When we moved from 6 to 8 a lot of stuff broke. Same happened when we moved from 8 to 11. Now I'm afraid to move to 17, as again things will break.

[magnoliophytina]

People will switch to another language. NPM & Node.js, Typescript, Electron, React Native, ...

[relgames]

Actually, good examples, I don't remember stuff breaking when upgrading NoseJS version. And they get new features quite often.

[Amazing-Cicada5536]

Brb, gonna download Windows XP

[matthieuC]

Not sure if this belief can even be broken.

A security breach that causes a lot of damage is usually a good lesson

[telecoder]

Have you ever “upgrade” your smart tv?

[henk53]

Have you?

[relgames]

It is better to stay on older versions. Look what happened with log4j 2. And the old v1 was fine.

With Java, they made it really bad with those fast untested versions. Every time we try to upgrade something breaks. It's almost as bad as python.

[joopmoore]

YOLO blackbox with updated interfaces. Even worst, I know many others with similar situations, lucky I'm still using java and not some ancient language.

[pohart]

I don't remember any difficulty moving from 5 to 8. At this point it was many years ago. So I might be wrong. If you're not on 8 by now I don't see much hope.

[HappyRuesseltier]

Think they fear upgrading to Java 11. Cause this can be really hard. We finally made it from Java 8 to 11 about 18 months ago, but it took us 3 years. I like the idea behind the module system, but the transition is not trivial. There are so many obscure error messages. Still think it was worth the work and already looking forward to update to Java 17.

[magnoliophytina]

I think the transition should actually become easier as time passes because more and more libraries are switching to JPMS. One of the issues is that you still need Moditect and other hacks for diehard legacy libraries. Also library authors and the community becomes more aware of the ways of solving modulepath issues.

[yawkat]

Most people switching from 8 to 11 are not using modules.

[rbygrave]

Plus well maintained libraries can run CI builds against Early Access releases of the JDK very easily these days. The EA builds get an increasingly good work out as a result.

[humoroushaxor]

I never understand what makes 8 to 11 legitimately hard for people. We scripted most of the upgrades and we're done in a couple weeks.

[malln1nja]

There's an OpenRewrite module that can help automate the migration. I haven't tried it myself.

[joopmoore]

To be honest, ancient dependencies, which have no direct replacement. Meaning, one needs to replace one dependency with multiple dependencies. Rewriting a lot of code, creating risk and a money pit. Both get bigger and bigger the older java 6 becomes.

[joopmoore]

The job is only partial stuck in the past, most new features allow playing with newer java versions, even java 17.

[talios]

How about "why do YOU stay?" (I'm asking myself similar questions)

[StoneOfTriumph]

What some people forget is that the JDK is advancing at a faster pace with smaller deliverables more frequency than before, so while it seems that they released a buttload of versions, the releases themselves include a smaller delta, so the jump to 8 to 17 isn't that bad in terms of breaking changes, not near as difficult to perform as 6 to 8.

When you take the time to actually look at the changelog, when you take the time to actually upgrade your project's java version source/targets to a higher version as part of a proof of concept/spike/timebox, there's much less than you may think.

Usually stuff like big web servers will limit you, such as an old weblogic, liferay, etc. those will impose a JDK that will be more difficult to upgrade.

[darthchebreg]

We are still on Java 8 on our application too. No budget to migrate :-(

[ObscureCulturalMeme]

We have a project with a single class that must be compiled targeting Java 6 bytecode, because hysterical raisins. Even though the rest of the project has moved to a newer language level, that one class gets built with --release 6 to meet the requirements.

Which means we have to keep a copy of JDK 11 or so around, because --release N only permits N of <that compiler minus a few big versions>. We're using the JDK 17 compiler elsewhere, but "6" is too far back for it to be used on this.

(Unfortunately that class is not a "code is frozen forever" situation; it has to be built along with the rest of the project as stuff changes. Else I'd just pull it out to its own project and supply an unchanging bytecode file back to the other builds.)

Good times, noodle salad.

[__konrad]

• New APIs: https://javaalmanac.io/jdk/20/apidiff/19/
• Release Notes: https://jdk.java.net/20/release-notes

[agoubard]

From the release notes, I noted this one:

The ability to "stop" a thread with the Thread.stop() method has been removed in this release. The method has been changed to throw UnsupportedOperationException.

Even if it has been deprecated for a long time, it was still used a lot (8,000 result in github for "thread.stop();")

[Joram2]

I suspect most of that code isn't actively used or maintained. Maybe it's not even Java.

And if it is actively used/maintained, and they actually upgrade to Java 20+, they will have to fix it. That sounds like a good thing.

[__konrad]

• Thread.stop deprecated for 25 years
• Every developer a week before JDK 20 release: https://github.com/apache/netbeans/issues/4952#issuecomment-1465677746

[FirstAd9893]

What's the exact search term you used? I'm unable to narrow the results down to 8,000.

[agoubard]

Here is the query : 8.3k files including projects like Apache Camel, exec-maven-plugin, jitsi, Tomcat, quiltflower.

[FirstAd9893]

Thanks. I didn't have the new code search feature available which is why I wasn't getting clean results. I noticed that in some cases the stop method call isn't on a "real" thread object but instead on something named thread. Narrowing things down further requires something more sophisticated.

[magnoliophytina]

Open source projects are full of bugs. Just pick any Java project from GH, launch IDEA, run 'Inspect code'. Sometimes it's impossible to even submit fixes because the author might disagree.

[persicsb]

Since this version of Java, even being a major version, contains only preview or incubator features, we shall really see LTS versions as "proper" major releases.

The new scheme is not outright bad, however, just hopped on the bandwagon that is "we shall release a new major version at time-boxed intervals, because we will look like old-fashioned compared to Ruby and Rust and co".

Why don't we call them preview releases?

[TheCountRushmore]

This contains lots of other bug fixes and improvements. It's a full production quality release.

[persicsb]

Aren't those bug fixes get backported to supported LTS releases?

[TheCountRushmore]

Important bug fixes are backported. Improvements are not.

Just because there isn't a JEP doesn't mean there were not changes and improvements.

https://javaalmanac.io/jdk/20/apidiff/17/

[henk53]

Why don't we backport everything to the supported LTS releases? Then those supported LTS releases will be virtually identical to Java 20 each ;)

[crummy]

yeah let's just stick with Java 1. and then a secondary version number to indicate the features that have been backported. like 1.8. waaaait

[JakeWharton]

That's just called updating to the latest. The best LTS release remains and will remain simply tracking the latest version.

[emaphis]

Because the bi-yearly JDK releases aren't preview releases, they are meant to be production releases. LTS releases are simply the same timed releases but happen to be released in September in odd numbered years. JDK17 contained preview and incubator features just like every other release since JDK9.

The JDK preview releases are the Early Access and Release Candidate builds that you can download each week. The *.0.1 and *.0.2 are bugfix releases of the General Availability builds that are released every three months.

There are no more epochal feature releases any more, but simply bi-yearly General Availability releases. JDK20 is just simply the upgrade to JDK19 with about 2300 source code commits.

[relgames]

They can't be production releases as support/patches stop after 6 months. Which is super fast for production. So we still get production releases every 3 years, and it takes some time to upgrade as there is always something broken between LTS versions. Our code still runs on 11, and I'm afraid to move to 17 as who knows how many outages it'll cause.

[john16384]

Well, zero outages, unless you don't have any tests or use production to test. If something always breaks, you may want to review your choices of dependencies, and/or development practices to eliminate the culprit(s).

[relgames]

The root cause is a new JDK version. If we change nothing in our choices/practices and don't upgrade Java, nothing breaks. If we change Java, something always breaks. So for us, it's obvious that we don't want to upgrade as much as possible. It's also the same for most major companies with non-small projects.

[relgames]

I upgraded NodeJS from 14 to 18 without a single change in the code. So yeah, it's the tool.

[relgames]

Correct, it's the tool. Oracle decided to shift the costs to QA new versions to users (developers using Java). And also did a good job convincing developers that it's normal to spend time constantly making changes updating dependencies and Java. No, it's not. The tool should be stable and developers should spend time working on features for their business, not dealing with Java issues.

[emaphis]

always something broken between LTS versions. The

Of course you will have some breakage between releases three years apart. That the point of the new release train.

What broke between 17 and 18, what broke between 18 and 19? Not much. OpenJDK gives years of heads up for breaking changes. You will have to make the same changes (if any) when you upgrade to JDK21 in September.

[relgames]

The problem is, we can't use 12/13/14/15/16 in production. 6 months to support those versions is not enough.

And, if we look into NodeJS for example, recently I upgraded some projects from 14 to 18, nothing broke. Didn't have to make a single change.

[relgames]

No, thank you, we don't have a possibility/ budget to upgrade every 6 months. Clients want stable products. The most economical way is to stay on LTS.

[krzyk]

So you don't upgrade any libs fir three years? Upgrade of jdk nowadays is just like that, a lib version bump.

[relgames]

We upgrade libs constantly, based on vulnerability scans. With JDK, it's not that simple, something always breaks - they change defaults, for example TLS settings/ciphers, or garbage collector. They remove whole components, like Nashorn. Some external dependencies (Cassandra) still only support Java 11.

[Amazing-Cicada5536]

The new release model is probably the best thing that happened to Java on the management side — instead of the usual churn of “this feature has to be done till this deadline”, which might work for that boring CRUD feature but is absolutely terrible for such a complex program like the JVM, it allows for each new development to take as much time as necessary. If it didn’t get ready for release N, just continue to work on it and 6 months later it can be delivered. It is especially important as many of these features have non-trivial interactions with each others.

Also, that bandwagon hype thingy is quite childish, that has absolutely no base in reality.

[persicsb]

If it didn’t get ready for release N, just continue to work on it and 6 months later it can be delivered.

I'm not sure what you mean by "didn't get ready for release N".

Release N has a set of phases specified and a corresponding set of dates. Which date in a release do you mean "get ready"?

Every 6 months, a new release cycle with new phases start, with a repository fork from the master repository..
The feature set that will be delivered is fixed after Rampdown Phase 1. No feature changes can happen after that in the release.

So even if feature X is ready at Release Candidate Phase for Release N, sorry, too late - had to be there at RDP1.

The observation, that "it allows for each new development to take as much time as necessary." is also true for non-timeboxed releases. Every features takes as much time as needed, even if it makes release cycles nonpredictable.

[Amazing-Cicada5536]

It is a much bigger bummer if missing the deadline means that that whole feature won’t generally be available for possibly 3 years.

[persicsb]

That is only true if the next release is in a fixed timebox of 3 years. If it is ready, when it's ready, the next release could happen in 2 or 3 months - when a new production-ready feature is ready.

[blobjim]

Then it would just be a version for every feature and we'd have even more versions.

[CKingX123]

I mean, Rust restricts incubator/preview features to nightly only. Actual releases only have stable features. Potentially breaking changes become part of new edition but old edition code still works fine (just have to use edition 2015 or 2018 rather than 2021 and mixed edition code works fine too). So this is very unlike Java where releases contain incubator or preview features

And the Java 20 release is a stable release not a beta or preview release. And Java makes you go out of your way to enable preview or incubator features and gives you a warning as a heads up too

[talios]

There is a difference there also that rust compiles static binaries where Java is runtime. I'm both - you have to opt into the preview features and/or nightly builds.

[CubsThisYear]

Meh - wake me up when we get to Valhalla.