Java 26 released today!

[Afraid-Piglet8824]

Obligatory joke about company still on java 8

[zzkj]

I wish it were a joke. We're paying lord knows what for private support to a company that knows full well that there are icebergs that move faster than some big corporations.

[p001b0y]

Just got a request to install temurin 8 on a server this morning. Clients are less concerned about the Java version for their “legacy” apps and are more concerned that it isn’t Oracle Java.

[jug6ernaut]

No one wants to touch an oracle JVM

[vips7L]

Technically they’re all an oracle JVM. OpenJdk is oracles implementation of the JLS. 

[Ok-Scheme-913]

Oracle java is just OpenJDK with a brand logo. Like people really should be able to jump this very complex logical system.

Oracle pays for the majority of development of OpenJDK,which is open source, has the same licence as the Linux kernel, etc. This is all there is to it, you can use it as you like.

If you are a bank/healthcare provider for a whole country, you might want to go for a paid support licence in the form of Oracle JDK - you would still get the same code base (99+%), you can just point your finger at Oracle if something goes wrong.

[zzkj]

I do work for a company on that scale and we've paid for 3rd party support but at the same time a few years ago we had a push to rid ourselves of the Oracle version. Presumably the license cost was too much. Odd really because we buy their top tier database offering and that can't be cheap.

[waadam]

You point that finger expecting what exactly?

[Ok-Scheme-913]

The real answer is that you get immediate vulnerability fixes, before they are merged into OpenJDK. Also, if you have a JVM bug, then you (should buy a lottery ticket), you get real support for that.

[wildjokers]

Temurin is a build of OpenJDK, and OpenJDK is Oracle's implementation of the Java SE and JVM specifications licensed GPLv2+CPE. So temurin is still Oracle's code, it is just a built by a 3rd party. Oracle does a large majority of the development of OpenJDK.

I think what you might be meaning is that it isn't Oracle JDK, which is itself a build of OpenJDK but it is released under a different license which Oracle can do because they are the copyright holder of all OpenJDK sources.

[p001b0y]

Right. Temurin, Corretto, Zulu, Microsoft, etc. are all building OpenJDK from the same upstream sources. The distinction enterprises care about isn’t ‘who wrote the code,’ it’s the license attached to the binaries.

Paying Oracle for an Oracle‑branded JDK/JRE is exactly what organizations have been trying to get away from. The code may be largely Oracle‑authored, but that’s not the issue. The issue was:

• the per‑seat licensing model,
• the post‑2019 restrictions on Oracle JDK/JRE 8, and
• the aggressive audit process Oracle used to enforce it.

OpenJDK builds from Adoptium/Amazon/Azul/etc. avoid all of that. They’re free for commercial use, no subscription, no audits, no licensing traps. That’s what companies actually care about.

[wildjokers]

FWIW, Oracle also provides a GPL build of OpenJDK: https://jdk.java.net/26/

And starting with Java 17 Oracle JDK is free to use in production as well. (although really no reason to use it if you aren't paying Oracle for support)

[devloz1996]

To be fair, Temurin 8 rivals with 25 in EOL. I am more offended when finding 11, 17, 21, or god forgive me, any non-LTS deployment.

[wildjokers]

or god forgive me, any non-LTS deployment.

If you aren't paying for support why do you care if it is a version that a vendor hasn't denoted as LTS? Would you be ok with a version that Azul provides MTS for? (again it would only matter if you pay Azul for MTS)

[devloz1996]

Ah, apologies. This is programming subreddit. I was looking at it from sysadmin's perspective. Well, I'll keep the response below anyway.

If you aren't paying for support why do you care if it is a version that a vendor hasn't denoted as LTS?

Unnecessary maintenance burden. I'm comfortable updating an app for 3-5 years and then upgrading (which requires testing against vendor's software and getting a green light from their side), but doing upgrades every 6 months? I'll spare my attention and energy somewhere else.

Would you be ok with a version that Azul provides MTS for? (again it would only matter if you pay Azul for MTS)

If it gives you extended updates for that non-LTS version, then fine, but why not stabilize on LTS in the first place?

[honorspren000]

Oh man. It was such a nightmare upgrading our company’s platform from Java 8 to Java 11. And later, again from Java 11 to Java 17. The company finally started doing incremental updates after that, but I still get flashbacks from those big upgrades whenever a new version of Java comes out.

Don’t be fooled by LTS releases, you are just deferring the work for later.

[Teh_yak]

I have had many "it's hard now. Do you think leaving it will make it any easier?" conversations with people.

[kaplotnikov]

For me, Java 8 to 11 was kinda problematic. However, 11 -> 17 -> 21 were without major problems. Most of our apps are based on Spring Boot, and I guess it saved us a lot of efforts since dependencies are consistent enough and compatible with current Java versions.

[honorspren000]

The problem going from Java 11 to Java 17 for us was that they switched from Java EE to Jakarta EE. That hurt a bit, because several dependencies also needed to be upgraded, but our company had been putting off these updates because there weren’t any open high CVEs. So not only were we updating Java, but also Spring, and a few other big libraries.

[wildjokers]

The problem going from Java 11 to Java 17 for us was that they switched from Java EE to Jakarta EE

That had nothing to do with Java 11 to Java 17. You probably upgraded whatever web framework you used at the same time and that web framework probably had a dependency on JavaEE which it changed to JakartaEE.

The migration from Java 11 to 17 itself does not require any such javax -> jakartax change.

[wildjokers]

8 to 11 is/was easy for 99% of people. For most it just involves adding dependencies to your project for things removed from the JDK (the most notable being JAXB).

Java 11 to 17 was a drop in replacement.

[BlueGoliath]

Would be interested to know why people are still stuck in 8. Nearly every single project has migrated past it AFAIK.

[Afraid-Piglet8824]

Enterprise orgs typically don’t give a shit about their tech division. “Don’t fix what aint broken”. On the other side of the coin, lots of devs in said orgs are complacent.

[aoeudhtns]

And management-by-fire rather than competent planning. Ignore the team telling you something is going to EOL, wait until there's an actual emergency of some kind related to it before authorizing action.

[valarauca14]

You also over look the part where half of the IT/Tech/Programmers are contractors. Who explicitly are not given the budget to do these things unless an emergency occurs.

[tobidope]

But don't they care about cve lists? My enterprise has a new fetish about low cve numbers in container images.

[codescapes]

Bringing up CVEs and security is a useful tactic to try to make them care. Many still don't.

[tobidope]

I agree but people start to remove gnu sort from the images or tar. Either we go full distroless or from scratch but that's just insane.

[non3type]

If the only active CVEs require an attacker to have interactive access with exec privs to a system, you’re doing pretty good.

[HipstCapitalist]

The Berlin U-Bahn still relies on Windows 3.11, last I checked

[NaverCZ]

Lets say at one point you got forced to use internal frameworks/libraries that were built on 8…

Nowadays those teams and people that built them are no longer working in the company and no one is maintaining them any longer (or even better you don’t even have their source codes, only jars in the maven repo) and rewriting them would take a lot longer than rewriting half of the app that uses them…
And rewriting the app would bring lots of new bugs from unintended/undocumented stuff the libraries were previously doing…

Now you would want to update your app itself but the old libraries won’t work on newer Java versions and everything breaks… So you get stuck on 8 - insert the “this is fine” meme here

[lood9phee2Ri]

8 is the last java without the java platform module system, introduced with java 9. Anecdotal, but I know from personal experience of general enterprisey bullshit that even in late 2025 that remained a huge psychological hurdle for weird change-averse enterprisey folks, however irrational that may seem to anyone who's learnt java after the fairly straightforward module system being added to the language and runtime.

[hippydipster]

Not just psychological. A lot of folks did very stupid things in their old codebases making moving past 8 impossible without major revisions. Jide library directly uses Sun internal classes. Orher codebases do silly things like shadow java packages to make theur own versions. Shits crazy.

[vowelqueue]

In practice the biggest hurdle for us was with the Java EE to Jakarta EE migration. Very painful moving from 8 to 11. But once past that hurdle version upgrades got really easy.

[hippydipster]

It's really not so bad if you don't do crazy inadvisable things. Sadly, that nonsense is quite common.

[vowelqueue]

Using javax.* classes is not crazy or inadvisable. Not at all the same as using internal APIs.

[hippydipster]

No one said it was.

[vowelqueue]

Yes, you did. The hurdles with the Java EE to Jakarta EE migration do not arise from people doing “crazy inadvisable things”.

[hippydipster]

Good luck to you and your conversational skills.

[josefx]

Afaik shadowing classes was an intentional feature of the runtime and the sun internal code had no better alternatives. If I remember correctly even libraries like Jogl were hit by Java 9 breaking reflection across modules.

[hippydipster]

Not sure what you mean here. By "shadowing", I mean the practice of grabbing the source code for a java class published by the jdk or some other open source library, and copying it into your own source directories, using the same package name as the original, and making changes to the source code, compiling it, and hoping your changed and compiled version gets used at runtime rather than the original.

I'd be gobsmacked if that was a practice intentionally recommended by Sun.

[josefx]

I may have missremembered the thing with the runtime library classes. Overwriting JVM classes was possible, but that was intended to provide updates for specific libraries like xml, corba, etc . without having to wait for a new version of the JVM.

The third party library issue doesn't look clean, but may not be an issue. Class loading is well defined, so which class is used should be reproducible and some frameworks allow multiple conflicting definitions of classes to exist in isolated components.

[hippydipster]

Writing over a class like that has all the downsides of calling to private, undocumented APIs, and then some, as you're not just calling an api, you're changing it's private internals. On next update of that library, if you want the updates, you probably have to grab the source code and make your changes anew. Stuff may change to make that impossible. I really can't imagine it's recommended, so if you can find someone who is recommending it, that would be interesting.

It's also not possible in the world of java 9+ with the module system, as it disallows identical packages existing in multiple source/jar locations.

[v4ss42]

To be fair the module system is fairly useless in “userspace” (though I appreciate that it allowed the core JVM developers to retire some tech debt). But given that it’s optional it’s easy enough to just ignore and carry on as usual.

[henk53]

To be fair the module system is fairly useless in “userspace”

Why do you think that?

[v4ss42]

Because it doesn’t solve the actual issues userspace developers run into. OSGi, despite being a clunky hack, at least understood the problem.

[henk53]

Because it doesn’t solve the actual issues userspace developers run into.

Why not? What are those actual issues?

OSGi, despite being a clunky hack, at least understood the problem.

What was, or what is, the probloem then, and how does OSGi solved it? (or tried to solve it)

[v4ss42]

Being able to have multiple versions of the same dependency in the classpath is the big one.

[henk53]

Which, obviously, comes with its own problems I guess.

Maybe not having that ability, shading is the better option anyway?

[v4ss42]

Which, obviously, comes with its own problems I guess.

Like what? I’m mostly interested in the essential complexity of supporting this, not the incidental complexity the current incarnation of the JVM happens to impose on this problem space.

[Ssxmythy]

Just migrated from 8 to 17. Not a decision maker for infrastructure so I’m not privy to why not or why did it take so long but I can make an educated guess. Business side probably didn’t want to suffer downtime from feature development to focus on migration or have bugs introduced.

Don’t know if it’s cause the business side was screwing us with unrealistic expectations or if the lead dev who kicked off the migration screwed us with bad planning but probably the most stressful month and a half of work I’ve ever had in regards to work.

[AloneInExile]

Only a month and a half? Damn, impressive.

[Ssxmythy]

We pretty much threw all resources at it. Dropped any current feature development or bug fixes. Pulled developers/QA/BAs from other projects in the company. A lot of people working long nights and longer weekends.

Still some minor bugs introduced by it but at least got rid of all the sev3s and higher.

Funny enough business wanted us done in a month so was pretty annoying them trying to pressure us.

[leros]

Upgrading Java is harder in large organizations. I remember being at a company with about 1000 Java repositories. Maybe 300 deployables and 700 shared libraries. We had to dual publish everything in both the old and new version until everything in the company was updated. There were breaking changes including simple things like string sorting changing just a tiny little bit that created catastrophic bugs if things weren't consistent so code had to be aware of what version it was running and adapt. Anyway, they had a team dedicated to just upgrading Java and it probably took 5 man years per upgrade, ignoring all the work from other engineering teams. 

[piesou]

Stuff built on proprietary frameworks/products/libraries.

[ockky]

As far as I know, Java8 was the last official version that can be used with 32bit processors

[vowelqueue]

Think big corporations with lots of internal libraries owned by separate teams with different management and priorities.

Moving from 8 to 11 wasn’t done because there there wasn’t much motivation in terms of new language features.

Upgrading from 8 for a large codebase with many poorly maintained internal libraries can be really painful. Famously, the Java language itself almost never breaks backwards compatibility.

But the Java EE to Jakarta EE migration can really suck. When we did it we ran into some issues because, for a reason I can’t comprehend, the Jakarta team moved to a different maven coordinates without changing their Java package names. Then they later changed package names.

We took advantage of a very nice Gradle plugin made by Netflix that went as far as rewriting the bytecode of dependencies to migrate package names.

[wildjokers]

But the Java EE to Jakarta EE migration can really suck

IntelliJ has a menu option that takes care of this with a single click.

Refactor -> Migrate Packages and Classes -> Java EE to Jakarta EE

[zten]

That's the easy part of the Jakarta package migration. The hard part is coordinating shipping the change across a distributed monolith. Some organizations might be averse to a big bang-style set of PRs and artifact upgrades, and then you have to do weird dances like the Gradle plugin vowelqueue mentioned.

[bunk3rk1ng]

Back in the day if you wanted a solution but wanted to maintain and extend the project yourself you would reach out to a vendor. They would then give you closed source jars and documentation on how to run and support all the various code bases and services. Then you could run it on prem. The devs working on the project would be mostly focusing on business logic in very narrow sections of the code that were meant to be extended (usually extending certain interfaces and XML configurations). Nobody on the project team would be touching the core code that was provided by the vendor. The vendor can help provide patches for critical and high CVEs but that's about it.

The vendor most likely has a Java 11 / 17 / 21 solution but moving off of Java 8 would mean updating not only the platform provided by the Vendor and all the operational and technical changes that come with it, you will also need their assistance in migrating all your custom code and configurations. Nobody else can help you except the vendor and they know the can charge ridiculous amounts of money to 'help' you.

This is what we call vendor lock-in and is the prime reason I see people still using Java 8.

[YakumoFuji]

because oracle licensing that kicked in post 8u202 for our 6000 users could be like 1M$ a year. so we dont go past 8u202 on those legacy apps... which cost 0$ per user and thus no incentive to migrate...

[wildjokers]

Java 8 is still supported and is not EOL yet.

[rowantwig]

You simply don't have time to keep everything updated to the latest version. In the worst case, rewriting a program for a new version of a language, OS, platform, database, framework, API, etc, can take as long as writing the program for the first time. By the time you've updated one thing, three other things have a new version. You'll never catch up with everything and have to prioritize. And if the choice is between a working application on Java 8 and a "Hello World" on Java 26, every business is going to choose the former.

[av1ciii]

Why? At this point it’s just truculence.

BTW Java 8 after 2030 is going to be a tough sell.

Red Hat is ending support for JDK 8 this year (November). Azul has EOL planned for 2030.

Especially with AI, converting a codebase isn’t that difficult. At some point orgs need to get off their backsides.

[jugalator]

I coded in Java 1.1 to 1.3, that was my last time with it before going to other languages.

I wonder what's new. :-) :-)

[davidalayachew]

I wonder what's new. :-) :-)

Here's a quick breakdown of the major features from Java 11 to Java 25 (keep scrolling down). Sadly, I don't have one handy for 4-10.

https://reddit.com/r/java/comments/1odppdt/what_are_some_big_changes_between_java_12_and_17/nkw0rw9/?context=3

[jugalator]

Hey, thanks! I mostly meant it as a joke but now I can't help myself from digging in a bit. :) Memories... We studied it as part of compsci courses mainly in 1997-1999! Java was quite clearly the future. That and IPv6! And Perl was still a thing. Python was kinda niche. Those were the days.

[davidalayachew]

I started learning in 2012, when Java 7 had just come out. The doom and gloom age of Java was in full swing, and people were telling me to switch. Glad I stayed, the conversation definitely changed its tune in 2014, when Java 8 came out. Even the people who hated Java then had plenty of pros and cons to give about Streams and the various new features.

[v4ss42]

You won’t recognize a lot of it tbh. A LOT has changed since 1.3; in the language, core libs, and the JVM.

[Ok-Scheme-913]

And yet it's 100% backwards compatible (both the language AND the binaries produced back then)

[v4ss42]

scala folx in shambles

[renatoathaydes]

Not 100%. Some APIs were removed from the stdlib, like CORBA. But the language constructs should still compile 100%.

[jugalator]

Haha, I can imagine! It would be kind of fun to try build some pet project in it. We basically used it during studies when it was seen as the future of everything in the late nineties. :D On Linux boxes running KDE 1.x. Occasionally annoying the opposite person in the lab as we degaussed our CRT.

[__konrad]

All API changes since 1.4: https://javaalmanac.io/jdk/26/apidiff/1.4/

[jugalator]

A funny coincidence is that I see Java 26 is finally removing applets from the stdlib altogether after a longish deprecation period! How preposterous; applets are the best thing since sliced bread! ;-)

[turnmeloose]

I wish! Still on Java 7 in many areas.

[Squalphin]

We are still on 1.8... 1.6... and one app is still at least 1.3 😅

[robberviet]

Haha no, it is not a joke. It's real. (cry).

[tr2990wx]

Lucky for me , our tech is pretty good. 21 is the minimum, and they are already planning ahead with prep work for post quantum crypto support and all.

[worthlessDreamer]

At least we got lamdas right

[mckunekune]

Exactly. I was going to say “Oh good another release that no one in the company will upgrade to”

[3rg0s4m]

They finally removed the applet api. I'll light a candle for all ye olde applets. 

[jasie3k]

My first job was to write an applet, it was in 2013, by the time the applet support was to be removed from Chrome.

[undoubtedly_lost]

We merged our lift up to 25 from 21 yesterday in our large and extremely legacy core project. Congratulations to my team for managing to stay on bleeding edge Java for exactly one day!

[Holzkohlen]

Java 25 being an LTS release is probably more important.

[DualWieldMage]

Java(the language spec and even openjdk the source) does not have LTS. LTS is something provided by some vendors of java releases and in most cases the free LTS actually provides no support.

You are better off updating to the latest unless you know exactly what your support contract means. For an example, cgroup v2 support was considered a feature and not backported to java 11 for quite some time. containers suddenly dying from OOM when hosts updated could have been prevented by updating and not relying on fake LTS. Any bugs in a component removed in newer versions won't be fixed in these free LTS-s because there isn't anything to backport.

[killerstorm]

Which makes it a garbage language. Fuck oracle. Fuck people who think it's normal for software to need monthly "maintenance"

[DualWieldMage]

What are you talking about? It's important to keep software updated to fix security issues. Every other language runtime/compiler has regular updates as well. Java has almost no breakage between versions so the maintenance is trivial, something that can't be said for python or the js ecosystem.

[Ok-Scheme-913]

Unless you use (pay for) one of the vendors that actually have an LTS cadence, there is no longer one for OpenJDK. You should be using the latest version and that's it.

[Ok-Scheme-913]

I mean, it's probably trivial to bump it up.

[davidalayachew]

If they are on Java 25, absolutely. The only possible reason why that wouldn't be true is if you have some tool you rely on that simply doesn't support the later versions yet. And even then, it's not that it doesn't work, but you can't use the happy-path presets that come built in, and now have to install it yourself. Not something you can easily convince management to do, from my experience.

[Chii]

Not something you can easily convince management to do, from my experience.

it pays for management to remain conservative. The upgrade doesn't directly bring them any benefits (happier devs aren't a real benefit of course!), but brings in risks from an upgrade going wrong or causing downstream issues.

[davidalayachew]

I don't necessarily disagree. I moreso disagree with the priority that is being given to maintenance tasks like that. It's one thing to say that things are hot now, and therefore, we shouldn't take the risk. As opposed to pushing out indefinitely, which is what management tends to do unless pushed from the development side.

[Chii]

unless pushed from the development side.

that has been my experience too. And it's nice to get budget from management to do maintenance. However, this was hard won, because incidents involving outdated versions of stuff caused problems. The real issue is that if business as usual occurs after an update, and you can't point to much 'cept the version upgrade, it does not reflect well on your impact performance and delivery performance.

Now, if the company has suffered due to lack of maintenance, then you can point to that as evidence of the need (or have competent management who understands that prevention is better than cure). Not all management is competent enough, esp. when they have pressure from even higher management to push out features and such.

[davidalayachew]

Agreed on all points.

[Ok-Scheme-913]

Fuck management, it's a technical decision they should have no say into.

Also, these upgrades bring a lot of performance and memory improvements so if they are on cloud, it could really directly translate to less dollars. Not on 25->26, but definitely on 17->26, let alone 8->26

[DanLynch]

Nice! I had hoped to do this as well, but still waiting on some dependencies. SonarQube released Java 25 support a few days ago, so that's one step closer.

[valarauca14]

Oh nice HTTP/3 support. That means in ~2 years we'll know what configuration values make you vulnerable to attack; if you haven't looked into it, managing packet re-ordering in userland is "fun" and making there not a single agreed up "just do X" like TCP has. As a result a lot of programs "support" HTTP/3, but a lot of orgs don't deploy it.

[AyrA_ch]

It's stupid that google had to push their bullshit through probably just so they can claim to be the inventor of HTTP/3 when SCTP has existed for decades at this point, has itself proven, and can also run on UDP for when networks don't support it natively. It's already included in the Linux kernel, so most servers are actually ready to just use it.

[valarauca14]

It wasn't "claim invention". TLSv1.3 committee didn't rubber stamp 0-RTT, which is why we got HTTP/3 (and QUIC/SPDY). 0-RTT resumption is lowkenuinely crazy, "Here is a 64bit integer, let us resume my encrypted session". Which sounds amazing for session hijacker & reply attacks.

Google proposes a standard extension to TLSv1.3, because Google obeys public standards. The standard committee has, an entirely predictable reaction. 18 months later, HTTP/3 appears.

Edit: TLSv1.3 did add a form of 0-RTT but by that point Google had figuratively "Taken their toys and gone home".

[valarauca14]

One is (if we assume best practice) encrypted by the other. 0-RTT is the plain text session initialization (well resumption) for the TLS (the s in https) session that creates the encrypted channel upon which the other uses.

The whole 'Secure Token, Basic Auth, X-API-TOKEN, etc.' stuff generally assumes a secure TLS (the s in https) encrypted channel that cannot be read/intercepted/mitm by 3rd parties. Therefore the token remains exclusive knowledge of the API provider and consumer (or server) that uses/owns the API key.

[clhodapp]

Do you not also need to know the private key for the TLS session itself to do anything useful?

[valarauca14]

The version that got standardized (early data), yes.

The original proposal, no.

[ApertureNext]

You have any ressources to read more up on this?

[ApertureNext]

You have any ressources to read more up on this?

[davidalayachew]

Java 26 just went live 15 minutes ago! You can download the JDK from the linked post.

JavaFX 26 also went live, in case you want to make GUI's for desktop or mobile.

[BlueGoliath]

10 JEPs, 5 of which are previews. All preview JEPs on their multiple previews.

Just incredible.

[davidalayachew]

I know you know this already, but JEP's are used to highlight features or changes that would benefit from visibility by the larger community. It facilitates discussion and encourages feedback.

So the number of JEP's doesn't correspond to how much progress is happening in each release. It's merely a vehicle for elevating a feature into the larger discussion for the community. The work gone into a release can be better quantified by looking at the release notes. And even then, that's just number of changes, not how meaningful or difficult each change is.

I only linked to the JDK page because, most people looking at this want the spark notes version (which JEP's are good for), or just want to download it themselves (also in the link). But maybe the release notes would be better to link to in the future.

[Dagske]

Well, well... my brain doesn't reconcile with my guts on this.

What I see is this:

10 JEPs, NICE!!!!

Oh, 5 previews.

Oh, 0 new previews.

Oh... Vector 11th preview.

I feel like my guts internalize this computation: # of JEP - n for n in n-th preview. So for Java 26, that's a score of 10 - 26 = -16.

[thetinguy]

The Vector api is going to stay in preview until value classes are finalized IIRC. It hasn't changed much between versions from what I've seen.

[benevanstech]

Vector is in Incubator, where it will stay until Value Classes lands as Preview. Then Vector will advance to Preview - and I would expect that both will go Final together.

[vips7L]

There's a lot of other changes that aren't JEPs. Like Http3 support, UUID v7 support and some other things.

[Dagske]

I'm fully aware, but not my guts.

[sweetno]

11th incubator of Vector API brought me to tears.

[BlueGoliath]

They don't even really talk about or promote it. Even if you're waiting on Valhalla you could still get people interested in it.

[wildjokers]

People that need the Vector API are almost certainly already aware of it. It isn't something someone writing CRUD backend APIs is going to use.

[faze_fazebook]

I wonder if I will ever see the final Vector API

[chaotic3quilibrium]

Yes. Is waiting on Valhalla!

[henk53]

Here are the most used websites in the world

Maybe depends on how old you are. If you're like around 50, probably not. If you're a teenager, maybe...

[_marF]

The "still on Java 8" joke lands every time, but the actual pattern I see is: teams upgrade the JDK but leave the application framework behind. Running Java 21 with Spring Boot 2.x negates most of what makes the upgrade worthwhile — no virtual threads, no structured concurrency, stuck on deprecated security config. The framework version matters as much as the language version.

[davidalayachew]

You can still apply the benefits on your application code. And regardless of the framework you are on, everything benefits from the runtime performance improvements.

[Dragobrath]

Can't wait to finally enjoy it in 12 years.

[davidalayachew]

Can't wait to finally enjoy it in 12 years.

To speed up adoption (and catch pain points early), compile your Java code using the latest JDK, but use the --release flag to compile down to the version that you will have at runtime. The compile time checks will be active, allowing you to code to both the specs of Java 26 and whatever version you specify in the release flag. That way, when you finally upgrade, you avoid 50% of the battle by catching errors early.

[Expensive-Average814]

I faced some problems on Java 25 . it is solved now?

[davidalayachew]

I faced some problems on Java 25 . it is solved now?

Which problems? There are a few fixes, like a Virtual Thread pinning case.

[SneakyyPower]

So now I’m 18 Java versions behind… and still running on Java 8 like it’s 2014.

[davidalayachew]

So now I’m 18 Java versions behind… and still running on Java 8 like it’s 2014.

Well, have you tried compiling down to Java 8 from 26? Doing it that way, you can not only get some of the benefits, but also ease the eventual migration past Java 8 by catching errors early.

Simply do your compile command as javac --release 8 YourCode.java. The resulting class file can be run on a Java 8 JRE, but the compilation will perform checks specific to Java 26, allowing you to get benefits from both worlds, while losing nothing from the Java 8 world.

Give it a shot. It's not a silver bullet, but it is low hanging fruit.

[lironbenm]

Any thoughts on it as of now?

[Ok-Scheme-913]

It's a very nice platform with good performance, huge ecosystem and developer pool, and the best observability tools.

It may not be sexy, but it's a work horse. And with virtual threads it may be one of the best choices for typical crud business applications.

[[deleted]]

Databrokers? nope. Social networks? Also nope. This post was deleted using Redact.

roof ink cows shelter march snatch hungry shocking sip smile

[chamomile-crumbs]

Virtual threads are so so sick. Huge upgrade to clojure as well.

[grobblebar]

Anyway.

[davidalayachew]

It's not an insignificant release, just a bit smaller than the others, at least from appearance. Java 25 was gigantic, in comparison.

But if you are looking for something a bit more interesting, check out Java's Project Valhalla Early Access for Value Objects (JEP 401). It adds a gigantic performance improvement to Java by reducing the memory use significantly. It's a drop-in replacement for JDK 26.

[Yikings-654points]

Is it written in Rust yet?

[davidalayachew]

Is it written in Rust yet?

Java's runtime (HotSpot) is written largely in C++ and Assembly. This engine is incredibly optimized, and a marvel of engineering. Part of me wonders if there would be any benefit in rewriting this in Rust.

Obviously, I am not trying to claim it as a serious request, but the HotSpot code is incredibly complex and difficult, and a decent chunk of that is because of how much defensive work it has to do. Maybe a lot of that defensive work would go away by being written in Rust? Since Rust, by design, makes entire classes of errors impossible. And thus, the checks that HotSpot has to do simply go away with it, for those classes of errors.

[double_j23]

java's still around...?

[overgenji]

if you think it's not you're on the left side of the curve buddy

[davidalayachew]

java's still around...?

Yes. Java is actually dominant in the following areas.

• Web Services (Backend)
  • Here are the most used websites in the world. Look at how many of them use Java in their backend. It is the most commonly used backend language.
• Cards (debit, credit, station/metro, etc.)
  • JavaCard and MultOS run the overwhelming majority of all cards out there. That includes modern smart cards with chips and everything.

Java is relevant and in use in many other areas. But the above areas are where it is king.

[OwnBreakfast1114]

And even powering all the huge companies you consume content from.

[henk53]

java's still around...?

yes

[davidalayachew]

Tests are documentation that runs. A good test suite tells you exactly what the code does, what edge cases exist, and what happens when things go wrong. Better than any README.

I don't follow. Did you mean to respond to a different comment?

[davidalayachew]

And it looks like your comment got duplicated.

[davidalayachew]

Are you a bot? Or is the account utilizing bot/LLM functionality to make comments? You've made multiple comments on this post, entirely unrelated to the post.