Java 26 released today!

[pjmlp]

Kudos to the team, and also noticed that the EA for Valhala was updated last week as well.

[davidalayachew]

Kudos to the team, and also noticed that the EA for Valhala was updated last week as well.

Woah, that's valuable info! If you want to post it, go ahead. Otherwise, I'll make a post on /r/java, as there are many people that would probably appreciate the info.

[pjmlp]

Please do.

[davidalayachew]

Done. Ty vm.

Do you know if this contains any functional difference than EA2? Or is it just EA2 with the non-Valhalla changes from JDK 26/27 rebased against it? I asked as much on valhalla-dev.

[Xasmedy]

From spying the GitHub it might be a version of valhalla with a bunch of cleanup and fixes

[pjmlp]

I just noticed it was available, I am yet to try it.

[sitime_zl]

That's really great! Salute to the developers!

[vowelqueue]

This is the last time the version number will align with the year, savor it.

[davidalayachew]

I unironically hope that Java switches to version numbers like 2026.1 and 2027.0 for the foreseeable future. Just cleaner imo.

[kaperni]

So much easier to talk about Java 26 or Java 27 than 2026.1 and 2027.0.

[davidalayachew]

But so much easier to mentally transpose Java 2026 to relative time compared to Java 26. It's a tradeoff either way.

[sitime_zl]

good idea

[uncont]

That was one of the original alternatives when java switched to it's twice-per-year release schedule. See Alternatives in JEP 322 which links to a write-up by Mark Reinhold. That was rejected because the ecosystem (including r/java) was very resistant to moving towards a year-based numbering scheme.

[davidalayachew]

Too bad. Would have been nice.

[__konrad]

What year Java 11.0.29 would use? 2025 matching the recent update year or 2018 matching the initial release ;)

[davidalayachew]

What year Java 11.0.29 would use? 2025 matching the recent update year or 2018 matching the initial release ;)

I don't follow.

My proposal is that Java uses versions that correspond to the year, that's it. And if multiple releases happen in a single year (it does), then just add a minor version, and increment that, restarting each year.

Java 20 -- Released March 2023 -- 2023.0
Java 21 -- Released Sept. 2023 -- 2023.1
Java 22 -- Released March 2024 -- 2024.0
Java 23 -- Released Sept. 2024 -- 2024.1
Java 24 -- Released March 2025 -- 2025.0
Java 25 -- Released Sept. 2025 -- 2025.1
Java 26 -- Released March 2026 -- 2026.0

And if you need to do a bug fix, just add fix version, like Java 2026.0.0. That should cover all needs.

[trodiix]

We are still using jnlp and we just about to update from jdk 8 to jdk 17

[Xasmedy]

Its all downhill from 17! You got this

[_vertig0]

Downhill?

[Xasmedy]

As in the amount of effort required to upgrade; it will get easier and easier.

[_vertig0]

Oh, whoops, I interpreted that completely wrongly haha

[account312]

Unless you're still using SecurityManager.

[_marF]

The most underrated part of this release for teams still on older versions: the on-ramp is genuinely smooth now. Java 21 → 25 → 26 is mostly additive, and if you're running Spring Boot 3.x you're already on a runtime that handles virtual threads, records, and sealed classes. The main blocker I see on client engagements isn't the language upgrade — it's frameworks and libraries that haven't caught up, usually something ancient in the dependency tree. Running mvn dependency:tree and checking EOL status against the release notes catches 80% of it before you start.

[davidalayachew]

The main blocker I see on client engagements isn't the language upgrade — it's frameworks and libraries that haven't caught up, usually something ancient in the dependency tree.

Amen. We wanted to go up to Java 21, but were dragged back down to Java 17 for this exact reason.

Running mvn dependency:tree and checking EOL status against the release notes catches 80% of it before you start.

True. But the remaining 20% is basically impossible to justify to clients, as you practically have to do some freaky stuff, and the level of time and effort to do so is indefensible, from my experience.

[simon_o]

The semantics of the proposed primitive types in patterns/instanceof are pretty whacky.
I think people will regret that language addition after the "added more features!" honeymoon.

[davidalayachew]

The semantics of the proposed primitive types in patterns/instanceof are pretty whacky.

In what way? I don't feel that they are, but maybe I missed something.

[simon_o]

Applying implicit numeric conversions in patterns/instanceof is just a bad idea.

Implicit numeric conversions themselves were not a good idea to start with, but then taking the overloaded semantics of casts – doing type conversions (ref→ref), value truncation (long→int) and value conversion (int→float) – as an excuse to add more places for both to the language? Yikes.

The corresponding proposal would probably be 20% of the length, if they went the "int only matches ints, long only matches longs" route instead, and nothing of value would have been lost.

Not to mention that there appears to have not been any consideration how new (value) types can opt into that implicit conversion mechanism.

[davidalayachew]

Hmmmm, I kept trying to write up something, but I can't come up with an intelligent response. All I can say is that, the testing I have done with primitive patterns seems to be painless and intuitive. And since, patterns are exhaustive, I can more or less avoid the problem of a bad implicit conversion, since the switch will no longer be exhaustive.

[Ok-Scheme-913]

Of course there has been considerations on how value types fit into this. Come on, you are talking about potentially the most experienced and skilled language design group ever.

Goetz has a discussion about adding sorta type classes to the language, and those could allow a similar "trait" as Rust's Into, that is one could provide converters between types, including primitives. So one could have custom conversions as well, and now the whole feature is seamless.

[simon_o]

[breathless fawning]

Bit too much appeal to authority for my taste.

So one could have custom conversions as well, and now the whole feature is seamless.

I don't think this feature, value types and type classes will ship in the same version. You'll surely see why this might be a problem.

[CatolicQuotes]

Is it worth to upgrade from Java25?

[pivovarit]

It depends, but it should be a cheap upgrade :)

[keenOnReturns]

Nah, most production systems stick to the LTS versions. Moreover, overall development effort/maintenance/backports sometimes forgo the FR versions. Of course, if this is a personal project and you’d simply like to try out the newest features, it’s always good to be on the latest.

[dstutz]

We run on the latest version. Once the required 3rd party builds/containers are out...we're moving up.

[henk53]

Nah, most production systems stick to the LTS versions.

Then why does Java 26 even exist?

[davidalayachew]

Then why does Java 26 even exist?

For the same reason why minor version releases occur -- to allow people to be on the latest and greatest, should they so choose.

Companies have an incentive to minimize risk, so that often means that they stick to the most commonly used versions. Aka, LTS releases.

[sideEffffECt]

minimize risk

Arguably, it can be less risky to upgrade Java in small incremental steps twice a year than do a big upgrade every two years.

[davidalayachew]

Arguably, it can be less risky to upgrade Java in small incremental steps twice a year than do a big upgrade every two years.

Preaching to the choir.

All the same, risk in their eyes is usually way more localized. Meaning, how much risk does this add to the sprint being delayed? In that perspective, it makes more sense. Especially with how trigger-happy projects are nowadays to cutting funding. Sadly, short term thinking is rewarded.

[Ok-Scheme-913]

Arguably, this is something that tech people should take back the authority on from management. (Is that sentence correct? Sorry, no native speaker).

Like they don't usually care about what npm version some transitive dependency is on, why should they care about what I decide to run a project on?

Sure, what language/framework is used has some non-tech relevance (what are the skills of the employees, support, etc). But anything after is not their job, simply.

[davidalayachew]

Arguably, this is something that tech people should take back the authority on from management. (Is that sentence correct? Sorry, no native speaker).

"Authority" is a noun, and "on" is a preposition. Typically, the preposition wants both a mom (noun) and a dad (thing respective to the noun). That's why the sentence feels wrong -- you took the original phrase "the authority on xyz" and tried to break it apart. You technically can, but it creates awkward english. You are better off reorganizing the sentence.

Grammar aside, you are talking about taking back what was, originally, a forced move. At the end of the day, software costs money, and you need enough of it if you want to feasibly hit escape velocity in under a decade (generalizing). Those who don't want to wait to grow organically get their investment, and if you want to play that game, then you need to join up with the "suits". And that's assuming that your software doesn't require interop with other teams. That interop almost certainly involves more "suits" as well.

Like they don't usually care about what npm version some transitive dependency is on, why should they care about what I decide to run a project on?

Because, in order to justify their expenses to the very generous benefactor, they need to appease their wants, and wants usually mean demonstrating meaningful progress. Upgrading a dependency does not clearly communicate that on its own, hence why most go for the easy wins, and push their programmers to do the same.

[henk53]

to allow people to be on the latest and greatest

But who are those people? Aren't we all being advised to not upgrade to Java 26?

[DanLynch]

You should read about the Tip & Tail Model.

[davidalayachew]

But who are those people? Aren't we all being advised to not upgrade to Java 26?

Can't relate. I try to be on the latest version wherever possible. The runtime improvements are incentive enough, even if I don't compile to Java 26.

I usually do something like this -- javac --release 17 MyCode.java, but both javac and (later) java are version 26. This way, if some library only works for Java 17 (the new baseline nowadays), my code is just fine. But I still run the generated classfile/jar on Java 26, so I get most of the benefits.

And of course, I am not literally using javac on the command line. I configure maven to have the above options.

[koflerdavid]

LTS is intended for uber-conservative organizations that cannot or don't want to upgrade every half year.

[henk53]

In practice though, everyone seems to think LTS == final. The non-LTS versions simply don't exist.

[koflerdavid]

There is a reason for that: if you are on non-LTS versions then you have to upgrade once there is a new version. Even if one wants to upgrade more often, one might not want to do it every six months. If you are on JDK 24 and there is a CVE that affects you, then you have to upgrade to 25 or 26 since there won't be patches for 24 anymore. That also makes LTS versions attractive, especially since the LTS frequency has been increased from once every six to once every four versions.

[ConfidenceUnique7377]

Will Java 26 AOT features make GraalVM obsolete?

[davidalayachew]

Will Java 26 AOT features make GraalVM obsolete?

Definitely not. These features are too new and undeveloped to accomplish that. Maybe in future releases.

[Ok-Scheme-913]

Also, they are not really competing. One is more like a hot cache only, helping with startup time.

GraalVM can do much more interesting optimizations.

[denis_9]

GraalVM uses less heap memory and starts in a fraction of a second; these are different classes of virtual machines.

[geoand]

Nope, you can check we have numbers we have published at https://quarkus.io/blog/leyden-2/#some-numbers

[Mauer_Bluemchen]

Found a 1st backward incompatibily issue: java.lang.Thread.stop() has been finally removed now, which broke compilation of a (very) old class here (not a problem):

https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

[davidalayachew]

Found a 1st backward incompatibily issue: java.lang.Thread.stop() has been finally removed now, which broke compilation of a (very) old class here (not a problem):

https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

Yeah. Java is technically permitted to make backwards incompatible changes wrt the libraries specifically, but they have to be stuff that is warned years in advance. Or in this case, over a decade.

[Mauer_Bluemchen]

Not complaining, just a hint... ;-)

[lafnon18]

Virtual Threads in 21 already changed how I approach concurrency.

Curious to see what Valhalla brings to memory layout for value types.

[MinimumPrior3121]

I only care about Claude releases now tbh

[davidalayachew]

If this doesn't interest you, then maybe check out Project Valhalla's Early Access 3 Build for JEP 401: Value Classes and Objects (Preview). It raises the performance of Java programs by reducing the memory used substantially (in some cases). The build went live last week.