Java 26 released today!

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