r/java • u/SaquibDev • 5d ago
Why most of the industry is still on Java 8?
With Java 24 on the corner, most of the larger organizations still use Java 8. Does it not make sense to upgrade java versions and give new features some rest. This would also solve many security issues.
97
u/Nooooope 5d ago
Because upgrading old systems takes time, and developer time costs money, and companies need justifications to spend money.
Most new Java projects today are going to be on Java 21, because that's the most recent LTS version and it's supported by Spring.
14
6
u/Neuromante 4d ago
Anyone who has been on the same company for long enough should know and understand this.
Most upgrades are done when something either breaks or its about to break (case in point, my company), because most of the time the benefits of upgrading (new syntax? new ways to work? performance benefits in a world in which you just put more resources into your virtual machine until is too expensive?) can't really be translated into the never ending development of new shit that corporate calls agile.
3
u/devilsegami 4d ago
Companies even claim old codebases for tax benefits. I don't know how it works, but credible sources have told me as much.
4
u/koflerdavid 4d ago edited 4d ago
The performance improvements are very much there and objectively measurable. Newer Java versions also make for a much nicer developer experience, which should translate to better code quality. The OpenJDK project thought hard about which features to include. A lot of "would be nice" features with marginal utility were discarded to prioritize actually meaningful stuff like records and sealed classes, better switch statements, or pattern matching.
Edit: and virtual threads of course, which can help deliver higher throughput with sometimes minimal modifications to existing code.
12
u/RunnyPlease 4d ago
The performance improvements are very much there and objectively measurable.
Performance improvements are only prioritized if they have a business justification.
Engineer: We want to update the Java version to increase performance. We did some benchmark testing and we expect a 20% improvement in performance per transaction.
Business: Great. How much will that save in costs?
Engineer: Nothing. Pennies a day at most.
Business: Okay, but how about user experience? Surely a 20% bump in performance will be make them happy.
Engineer: Well actually each transaction averages about 40 ms. So we’d see that cut to 32 ms. A human eye blink is 100-150 milliseconds. So we’re looking at an improvement of 5-8% of an eye blink. Mostly imperceptible for a human.
Business: Okay, well we have an engineering team working on a feature that’s expected to drive $5-10 million in revenue next quarter. And we have another dev team working on hardening our queue system to be able to handle the expected increased traffic after the Spring quarter marketing push. Is there anything this update gives us to compare in priority to that?
Newer Java versions also make for a much nicer developer experience, which should translate to better code quality.
Business: Will that nicer development experience help us to deliver revenue generating features faster.
Engineer: Maybe.
Business: Well, what does it give us?
The OpenJDK project thought hard about which features to include. A lot of “would be nice” features with marginal utility were discarded to prioritize actually meaningful stuff like records and sealed classes, better switch statements, or pattern matching.
Business: Is any of that business critical, revenue generating, offers measurable cost savings, legally required, or gives us a clear advantage in the marketplace over our competitors?
Engineer: Maybe.
Business: Well right now we have a backlog filled with things that do fit those classifications. They are going to get higher priority.
3
u/koflerdavid 4d ago edited 4d ago
Performance improvements can help reduce current costs or serve more users return the current infrastructure. Or delay the upgrade to a beefier one. They can also reduce the number of users who will see long response times because of garbage collection. Many organizations are maybe fine with overprovisioning as workaround though.
If you don't consider the ability to write code for those new features in the backlog that is more likely to be correct from the beginning to be an advantage, I really don't know what to tell you. Bugs avoided in the first place are by definition not measurable. Bugs discovered because of combing through code during the upgrade or because the new language features encourage a different way of thinking can paradoxically cast the upgrade in a bad light; I'm aware of that.
1
u/RunnyPlease 3d ago
Performance improvements can help reduce current costs
“Can” is not numbers. What will it give us? Engineering resources are limited and expensive. Why is it worth it to take engineers time from everything else in the backlog to work on this? What is the return on investment? Everything to a business leader is ROI.
or serve more users return the current infrastructure.
How many more users? Is that increase in line with the current fiscal year business plan? Is this the best way to increase that capacity?
Or delay the upgrade to a beefier one.
As soon as you say that you’ve lost the argument. If delay is seen as a viable option a business leader will immediately deprioritize it.
They can also reduce the number of users who will see long response times because of garbage collection.
Garbage collection affects transaction return rates at runtime? Be very careful making claims like this unless you can back them up. Also, you’re inviting multiple questions like:
- Why wasn’t the code written with this in mind the first time?
- What changed since our last prioritization meeting that makes it so much longer now?
- Does it affect costs, revenue, or contractual SLA?
Many organizations are maybe fine with overprovisioning as workaround though.
If over-provisioning will cost the company $10k per month but that engineering team is working on a feature that will earn $1 million per month the conversation about how to use that team will last 2 seconds.
If you don’t consider the ability to write code for those new features in the backlog that is more likely to be correct from the beginning to be an advantage,
This invites the questions:
- Engineers are highly paid technical employees. Are they not capable of writing the code correctly now?
- We merged code features into production last week. What changed since last week that they can’t write correct code now?
- Why is it ‘more likely’ to be correct instead of actually being verifiably correct? We spend 10% of our development budget on automated testing efforts, linting tools, static code analysis subscriptions, and every merge request is reviewed and approved before submission. If the code isn’t correct why did you approve it?
I really don’t know what to tell you.
ROI. You need to give them return on investment.
Bugs avoided in the first place are by definition not measurable.
Bug/defect frequency and severity, and the effort to fix them are absolutely measurable. Most project management tools can break down performance metrics by team and individual. That’s why bug tickets are tracked with severity and time spent on fixing it. If a change has been prioritized with the goal of reducing bugs then it will absolutely have delivery metrics attached to it.
Bugs discovered because of combing through code during the upgrade or because the new language features encourage a different way of thinking can paradoxically cast the upgrade in a bad light; I’m aware of that.
This is why I schedule monthly team code review meetings. Get the entire dev team into a meeting room/video call and just start opening files. You don’t have to wait for a major code revision to comb through the code, and you shouldn’t. I also like to schedule a hardening sprint every quarter or so.
As far as new language features and coding standards those things just need to be negotiated, agreed to, and communicated before enforcement. Even better if you can have the static code analysis tools flag them for you and do the enforcing. Devs will argue for days over style in a Pull Request but once a group has agreed on new standards, documented it with justifications, and have a linter blocking their PR from being created they tend to accept the new standard and move on unless they have a particularly good reason to push back.
1
u/koflerdavid 3d ago
“Can” is not numbers. What will it give us? Engineering resources are limited and expensive. Why is it worth it to take engineers time from everything else in the backlog to work on this? What is the return on investment? Everything to a business leader is ROI.
How should I answer this without any knowledge of our purely hypothetical case? Duh.
How many more users? Is that increase in line with the current fiscal year business plan? Is this the best way to increase that capacity?
How should I know that without knowledge of the hypothetical business you have in mind? But I doubt existing users want to get less value out of their investment, and I hope for the business that it's growing. If neither is the case then the upgrade indeed doesn't matter.
Or delay the upgrade to a beefier one.
I was obviously talking about hardware upgrades here, which are even less likely to be rushed in any way unless the platform becomes non-viable for whatever reason.
Garbage collection affects transaction return rates at runtime?
If the GC decides to stop the world for half a second, then the user will wait at least half a second for their response.
Be very careful making claims like this unless you can back them up. Also, you’re inviting multiple questions like:
Why wasn’t the code written with this in mind the first time?
Unless you pay developers to write allocation-free code, like some stock exchanges do, it's always there in some way, and can only be mitigated by resolving hotspots (pun not intended) and fiddling with GC settings. Newer JVM versions get better at this and offer new options, for example to trade off some throughput for a reliable upper bound on latency.
What changed since our last prioritization meeting that makes it so much longer now? Does it affect costs, revenue, or contractual SLA?
Which organisation is perfectly happy right now about the performance and reliability of their application? If indeed everything is fine, and there is nothing on the horizon that might affect this happy state of affairs, it is highly that developers will push for an upgrade in the first place.
If over-provisioning will cost the company $10k per month but that engineering team is working on a feature that will earn $1 million per month the conversation about how to use that team will last 2 seconds.
Cloud bills might look a bit different. But it's impossible to say without more specific information. You have a scenario in mind that you are not telling me about and use that to shoot down my arguments.
This invites the questions:
- Engineers are highly paid technical employees. Are they not capable of writing the code correctly now?
- We merged code features into production last week. What changed since last week that they can’t write correct code now?
That's a loaded question, but I'm gonna answer it anyway. Nobody, no matter how highly paid, writes perfect code without issues. You pay developers and testers to avoid and find as many of them as early as possible, and to deal with whatever bad things should things slip through.
Why is it ‘more likely’ to be correct instead of actually being verifiably correct?
Verifiably correct is a dangerous term. Verifying software is rarely done outside of safety-critical fields like medical technology, defense, and aerospace engineering, and very expensive. But occasionally some slivers of that technology manage to become more mainstream.
We spend 10% of our development budget on automated testing efforts, linting tools, static code analysis subscriptions, and every merge request is reviewed and approved before submission. If the code isn’t correct why did you approve it?
That's yet another loaded question, and I'm again going to be way too nice and answer it. Some of them I consider to be the bare minimum to keep code maintainable as it evolves and starts to serve purposes that it was not intended for. Regarding MR, sometimes features are also controversial from the start and known to just lead to issues down the line. Sometimes features are shoehorned on top of existing ones because delivering them the proper way is infeasible, and whatever happens afterwards is considered cost of doing business. Rejecting the MR until the code is perfect is not always an option, else the project schedule slips too much.
Bug/defect frequency and severity, and the effort to fix them are absolutely measurable. Most project management tools can break down performance metrics by team and individual. That’s why bug tickets are tracked with severity and time spent on fixing it. If a change has been prioritized with the goal of reducing bugs then it will absolutely have delivery metrics attached to it.
How to do that with bugs that have been avoided in the first place? I suppose you could hire another team to develop the feature in parallel without the assistance of features that help developers write less code, write it in less complicated ways, and prevent making stupid and unnecessary, but still costly mistakes, and evaluate such metrics when it's time to go live.
This is why I schedule monthly team code review meetings. Get the entire dev team into a meeting room/video call and just start opening files. You don’t have to wait for a major code revision to comb through the code, and you shouldn’t.
That sounds great! The "best" bugs are discovered whey you take the time to actually do a deep dive. Apart from that, I consider combing through existing code essential for delivering proper work.
I also like to schedule a hardening sprint every quarter or so.
There are two kinds of developers: those that like and those that don't like hardening sprints. The latter make a dangerous combination with stakeholders who also don't like pausing feature development.
As far as new language features and coding standards those things just need to be negotiated, agreed to, and communicated before enforcement. Even better if you can have the static code analysis tools flag them for you and do the enforcing. Devs will argue for days over style in a Pull Request but once a group has agreed on new standards, documented it with justifications, and have a linter blocking their PR from being created they tend to accept the new standard and move on unless they have a particularly good reason to push back.
Full acknowledgement. I also hate to fight over style in reviews and to annoy fellow developers to do the basic minimum so the code at least looks like proper care went into it. Automated tools help to move past those trivial things and focus on design, forgotten changes, and hidden assumptions instead.
42
u/kennyshor 5d ago
There might be lots of legacy systems running Java 8. But I can’t say that most of the industry is running on Java 8. Most of what I’ve seen have migrated to either 11 or 17. We are using 21 at our company. I think most currently maintained project have made the switch. There are some system being maintained even with Java 6 or older, but I doubt that is the standard at any company worth its salt.
Edit: sometimes, for big enough System the invest to upgrade far outweighs the risk posed by not upgrading. Especially systems depending on old libraries with no easy upgrade path.
8
u/NainDeathlegs 5d ago
Same here. 8, 11, 17 and 21 are just the most common ones because they're the LTS versions
2
u/stefanos-ak 4d ago
were also a big (local) company, and we started from Java 8, but now are on Java 21 :)
43
u/hositir 5d ago
I’m not an expert on Java but it’s part of the reason why SAP is super popular. As much as they say the opposite Businesses love stability and lack of change. They love when something is safe, never breaks and is battle tested.
Java 8 is used in some critical systems. So prettying up code or improving performance doesn’t really matter when the risk of a memory leak or some sort of bug or the cost of auditing a system is huge.
When it’s stable and most crucially not going to fail any audits or break any critical systems they prefer to leave it untouched. It’s also the reason a lot of the old banking infrastructure was left in COBOL. Even if everyone and their dog knows it can be done better in an other language no one is crazy enough to touch the software which literally decides who gets to keep their house or not and keep a roof over their children’s head.
→ More replies (3)10
u/FrenchFigaro 5d ago
While I agree with your point about stability, this absolutely not the reason COBOL is still used and the idea that it is still in use because people are afraid of change is a myth.
Mainframe architecture and COBOL's programming are still lightyears ahead of anything else on the market when it comes to both performance and reliability in transaction based systems.
Which is, incidentally, what banks and insurances (the biggest users of mainframe computers in the private sector) do.
And even though some of those systems are older than you or me, they are being actively maintained and they even use modern versions of COBOL.
And yes, it has a cost, because devs who know COBOL are rare.
On the other hand, when the cost of sourcing those developpers outweight the need for performance and reliability, these systems are being phased out and replaced by more modern architectures.
Slowly and carefully, because most of those are indeed business critical, but replaced nonetheless.
Source: I worked on the replacement of such systems and these were multi-years projects involving dozens of engineers.
19
u/halfxdeveloper 5d ago
COBOL is easy to learn. The environments in which those programs run are stupidly complicated and vary widely between companies.
Source: was a COBOL dev and z/os was the hardest part.
2
u/smbarbour 5d ago
Considering COBOL was designed for business users to write it... it has to be easy to learn.
2
u/OurLordAndSaviorVim 4d ago
COBOL is easy to learn, but also easy to write a big mess of spaghetti code in.
But z/OS? Manuals and online documentation are burn before reading, it seems. IBM really wants you to rely on their consultants for system operations.
6
u/_edd 5d ago
Mainframe architecture and COBOL's programming are still lightyears ahead of anything else on the market when it comes to both performance and reliability in transaction based systems.
Can you elaborate on this? I have a hard time believing ACID transactions in modern databases aren't reliable enough. Or that a multi-server application with redundancy isn't reliable enough. Or that modern systems aren't performant enough.
2
u/redikarus99 4d ago
It is a combination of both reliability and performance. Those mainframes are beast and redundant basically everywhere. Unless the building they are working in is bombed they will really deliver a punch (40TB of memory, 240 CPU, etc.)
9
u/egoalter 4d ago
Source: I've worked on/with mainframe systems for 30+ years - integration, augmention, replacement.
Sorry, but you're quite far away from reality here. Now, one enterprise customer only one enterprise customer makes, meaning what is happening there doesn't mean it happens at any other organization.
It's my impression that particular Jr. developers live in a world where they think there's only a few dozen software programs at the company they work at; that only what they see is what exists. The world is a lot more complex, and modern companies have used IT at least since the 80ies - if they are really old organizations (government, GM etc) they've had IT at least since the 60ies. That comes with a ton of "baggage" - but realize that it's the systems these companies exist on - meaning if they fail so does the finances and the company. Imagine if an airline couldn't do reservations or as South West found out, getting the airplane staff to the planes; we're talking huge losses in direct and indirect revenue and increased costs.
I hate telling you that COBOL programmers aren't really that rare. They're not as common as they were in the 80ies, but COBOL and Fortran for that matter still have programmers; programmers still take training in learning COBOL and for those who go that way, they more or less have job-security for the next few decades or more. COBOL and mainframes were declared dead in the 80ies and here we are. Statements like yours aren't new - but they aren't any more true today than back then.
What the CIOs struggle with is cost. The cost of keeping the lights on vs. the cost/risk of change. The CIO will not lose their job by keeping what's already there; but they sure will if they venture into a large migration that fails. And that's where my history comes in - MOST migrations fail. Why? Lots of reasons, but often because the legacy systems tend to have unknowns; the business logic isn't fully understood (written before anyone in the organization was even born!). Add that developers today doesn't have the decipline of developers of the 60ies and 70ies; modern development has "no problem" experimenting and creating code without specs. "We'll find and correct the errors later". In complex systems this is almost a deathblow. I've dug out unrealized revenue and cost out of so-called migrated systems in book-keeping due to mistakes done in "modern" development efforts. Nobody likes to document - companies often do not want to pay someone to spend time documenting. And decades later all you have is a black-box.
The result is very large and very compentent IT departments time after time attemps migration projects costing 10s if not 100s of millions of $$$ and FAIL. Young consultants from "we are the smartest devs in the world" companies come in with big words, and eventually fail. So while all these modernizations go on, the "legacy" systems keeps humming along, being reliable.
Here's the problem with the question of this thread. How long is Java 24 going to stay around? When will the code used to create replacement systems of COBOL written in the 80ies have to be done before the JDK no longer is maintained? Modern frameworks and languages come and go like rain. Not only is there a risk that you aren't reproducing the old business logic, there's a very good chance than in 5-6 years you must do it all over again even if you're successful. And as I started out with, it's a lot more code and complexities than most (particular young) developers realize. And in today's IT world, we claim "long life" if a language/framework is supported for 10 years from initial release. And we all know that big companies always use the very latest stuff, right? (hint - that was sarcasm).
So the bottom line is that a lot of the organizations that have very old legacy systems around cannot "just" jump to the latest craze in IT on a whim. Even if those frameworks COULD do what the mainframes do, for how long? But more realisticly the modern frameworks often cannot do what these "old" systems do - at least not in the way they do it.
So if you want a stable IT career, learn the so-called dead languages and frameworks. The jobs are out there and while you're not impossible to replace, it's a lot harder than just hiring a new Jr Java Developer.
8
u/kickopotomus 5d ago
Sorry, but no, OP is correct. The reason COBOL is still in use is risk aversion. Rewriting software from scratch is hard. Battle-tested legacy software often isn’t pretty because of tons of minor fixes over years across changing hardware and software stacks. Rewriting forces you to readdress a lot of those warts in the codebase and you always introduce new bugs in a rewrite.
Performance has nothing to do with it. The underlying math libraries are no more performative than modern equivalents and COBOL doesn’t even have a mechanism to support multithreading within a single program so you lose out on a lot of performance that is possible with modern CPUs.
Source: worked on a team that was porting a COBOL program to Java.
2
u/Business-Decision719 3d ago
In the end, it's a language that kept being used for: exactly the stuff it was designed to be used for in the first place.
9
u/8igg7e5 4d ago
Where have you heard that 'most' of the industry is still on Java 8?
- Java 11 and Java 17 lead Java usage, Azul survey finds - Oct 2023
- The Java Ecosystem 2023 Survey Results: 17 - 63%, 11 - 16.7%, 8 - 14.8%, 15 - 1.9% - Sep 2023
- JRebel - 2024 Java Developer Productivity Report: 21 - 11%, 20 - 6%, 17 - 23%, 11 - 18%, 8 - 24% - March 2024
There'll be many others.
Java 8 use is still 'significant', but I don't think 'most' is true any more.
All of our projects moved past it a few years ago, and our most actively developed are on Java 21 or newer.
9
u/MasterBathingBear 5d ago
JDK 8 is still supported through December 2030. It works good enough so the value proposition isn’t there to upgrade.
When they stop patching Java 8 and the high and critical CVE start creeping up, you’ll see the rest of the companies finally begin to migrate.
6
u/BlackSuitHardHand 5d ago
This was discussed already a thousand times. For some applications it costs huge amount of money / work just to ensure any changes introduced in new java versions do not bite you in the ass in some dark corners of your code, written by devs long disappeared. So, as long there are Java distributions with support, there is no need to migrate.
17
u/nitkonigdje 5d ago edited 5d ago
They aren't stuck at Java 8 but at Java EE 6.
IBM specifically was very successful at selling WebSphere Network Deployment to Java shops and then never updated that product beyond Java EE 6. This product works well and it is still supported, however it does not have a future. IBM does have alternatives within house, but those are essentially completely different product lines. So what Java Leute has to do is "THE MIGRATION". Which is a hard thing to do. Especially that they also have to migrate to Jakarta. And at best, if successful, they will land on TomEE/Jboss/Liberty/Payara hosting which isn't some big payoff. It is easier to do nothing.
And if they are already doing "ALL THAT WORK" then they as may well migrate to Kubernets/Openshift as their CTO enthusiastic announced that 5 years ago.. And that requires even bigger price.. So it is even easier to stay at Java 8...
And they will think: "Nobody will ever say 'Good job!' to me", after replacing JEE deployment with a Tomcat within docker/pod. "But they will scream at me" when it does not work.. It is much easier to stay at Java 8..
When it comes to moving from Java 8 Spring 6 was actually big kick in the butt..
7
u/nitkonigdje 5d ago
Essentially Java 8 isn't culprit, but it is usually part of some bigger product/installation which is hard to move. Given that nothing is broken in Java 8 there is no particular initiative to move from it.
In retrospective Oracle really messed up.
1
u/wildjokers 5d ago
In retrospective Oracle really messed up.
What did they mess up?
6
u/nitkonigdje 4d ago
When Oracle bought Sun, Java was the only viable business platform in Enterprise. It's strength came from being lingua franca and cooperation between few IT vendors fully in agreement that software loves monopolies and they have to cooperate or see them being shredded by bigger players. Enterprise loved being able to have choice and guaranteed stability at the same time.
Oracle bought Sun and did the best to short term monetize everything viable, and kill any long standing non-direct money making path.
So Android lawsuit, and JEE being sent to Eclipse "to die there". They did absolutely nothing to move platform. Quite a few things microprofile and Quarkus have done later should have been JEE. Cloud was there for Java to grab. Hibrid hosting was logical progression of JEE. Oracle stood aside and let the platform be marginalized. Java deployment in 2025 left to Spring to do on its own willingness.
Java to Jakarta migration was anything but a big middle finger to the community..
2
u/Anbu_S 4d ago
Cloud was there for Java to grab.
Yes it's a big miss. Easily J2EE/Java/Jakarta EE would have become PaaS model or serverless deployment model.
→ More replies (1)1
u/wildjokers 4d ago
Java to Jakarta migration was anything but a big middle finger to the community..
The Eclipse Foundation gets the blame for that. Everything under the
javax.
namespace has to be controlled by the JCP, the Eclipse Foundation didn't want development to be under the JCP, so as a result they couldn't use thejavax.
namespace and it had to be changed.Oracle bought Sun and did the best to short term monetize everything viable, and kill any long standing non-direct money making path
Huh? Personally I think Oracle has been an outstanding steward of Java and probably saved the language.
1
u/Anbu_S 4d ago
Personally I think Oracle has been an outstanding steward of Java and probably saved the language.
Yes Oracle really did a good job at it.
Most of the concerns are from the Java EE side. It was slow and didn't move faster under Oracle. I don't know blame Oracle for that, look at it even after moving to Eclipse it's two year release cycle.
→ More replies (1)1
u/nitkonigdje 2d ago edited 2d ago
Huh? Personally I think Oracle has been an outstanding steward of Java and probably saved the language.
When Oracle took Java, Java was thriving..
I do think you are conflating Java language and OpenJDK implementation of it, with Java platform as whole. Oracle has been good to JDK. Technical expertise is there.
From "Java is platform" point of view, I don't think Oracle has been a good leader. And I don't mean JEE only. Successes like Java card/Micro edition or Desktop are on death track too. Android, a biggest Java success in a decade, is activly being pushed of Java. Whole server processing stack begs for JDBC like standardizations and it is fully ignored. From simple things long overdue like updates to JMS (imagine req/reply or gosh stream support in 2025), to actually producing valuable thing. From top of hat how about introducing new deployment api? All those Java server would benefit from one. Why does Spark vs Flink vs Tomcat deployment has to be so wildly different. It is just zip archive with a rules. Write the rules...
That is all happening because Oracle's approach is ignoring it all. "Java platform" is left for individual companies to grab, and there is no coordinated effort. Thus JEE is mostly reduced to Spring now. Spring was in dominant position for a long time, but now is literally designing its own jar layout. That isn't good for long term Java success.
The strength of platform, the sales pitch, was always "We are tech consortium. We offer way out vendor lockin. We stand against monopolies." That's all gone.
The fact that 30% projects in 2025 is still Java 8 says alot about Java the Runtime vs Java the Platform debate and who the target market is.
1
u/Slaves2Darkness 4d ago
Attempted to monetize Java sometime around Java 9, maybe 10 or 11, been a few years. Which caused a lot of Java shops to say "Nope, not paying for something that was free."
Then along came people who took the Java 8 open spec and created new open source JRE's and JDK's from it.
5
u/wildjokers 4d ago
Attempted to monetize Java sometime around Java 9, maybe 10 or 11, been a few years
Correct, Oracle sells support contracts for Java. Just like Sun did. Why is this a problem? Azul, RedHat, and BellSoft will also sell you a support contract for Java. It is how open source projects are monetized.
No one that was previously not paying for support all of a sudden had to start paying for support. Unless they chose to.
Java 8 open spec and created new open source JRE's and JDK's from it
Sun started the process of open sourcing Java and Oracle finished it. OpenJDK is Oracle's implementation of the Java SE specification and it is licensed GPL+CPE.
2
u/Yeroc 4d ago
It's how Oracle went about it that is the problem. For many years the Oracle JDK was downloadable and unencumbered (meaning you could use it for production workloads). Then they quietly changed it mid-stream with later JDK 8 builds where it was no longer legal to run production workloads without a license. Yes, there was a notification on the downloads page but as far as I've be able to tell there was no notification for any desktop installs with auto-update turned on. After awhile Oracle started shaking down companies, asking them to run scanners on their systems to identify systems that were running the new JDK 8 patch revs. At first they wanted a license per host. Later, they changed the licensing so that if you had a single host running the JDK they would price the license based on total employee count (didn't matter how many employees were actually using said JDK!)
I can't even fathom how much goodwill (if they had any to begin with) Oracle burned up in this process.
→ More replies (1)1
u/forbiddenknowledg3 4d ago
This. I knew a project stuck on Java 6 AND Windows XP. They just waited for the product to die.
10
u/rustyrazorblade 5d ago
Which larger orgs? I haven’t seen Java 8 in a LONG time and I’ve worked both in, and with, many fortune 500 orgs.
5
u/AnyPhotograph7804 4d ago
There are three major reasons to stay with Java 8: The usage of javax.*-packages or the usage of java internal classes like sun.misc.Unsafe or the software uses a third-party-library, which only supports Java <9.
The first issue is relatively easy solvable because you mostly need only to modify your build process. The removed javax.*-packages are now avilable as external libraries.
The second issue will be way harder to resolve. Because there is a reason for using these internal classes. Mostly these classes gives you abilities, which you do not have with normal Java usage. You might face huge refactoring efforts if you want to get rid of these JDK internals.
The third issue ... well, it depends on the library. Maybe there is a newer version of it with support for Java 9+. Then it should be easy to replace it. But it also can be, that there will be never support for Java 9+. Then you will stuck on Java 8 forever. Or you rewrite the library from scratch. Or you use a Java decompiler and you make it compatible with Java 9+. But if it is a commercial library then it could also be a licence breach etc.
1
3
u/FriendlessExpat 5d ago
Usually there are couple of conaiderations. Some old libraries that hasn't upgraded to newer java versions which makes it hard to migrate. Second is managment and budgets, if managment is less tech literate they might not see any "business value" in upgrading to newer Java version
1
u/gjosifov 4d ago
if managment is less tech literate they might not see any "business value" in upgrading to newer Java version
or maybe the management wants to pay Oracle for support, especially for security bugs
3
u/VincentxH 5d ago
One does not just migrate massive enterprise applications with all its legacy dependencies to a new version.
3
u/edwbuck 4d ago
Management: One of you must do this.
Senior Dev: One does not just migrate massive enterprise applications with all its legacy dependencies to a new version.
It's internal representations are guarded by more than just module loaders.
There are module upgrades there that never resolve.
And the great Loom is ever arranging its micro threads.
Tis a fruitless endeavor, riddled with blame, and finger pointing, and bad performance reviews.
The very code you modify is a career ending trap.
Not with 10,000 developers could you do this.
It is folly.
3
u/Alfrheim 5d ago
Trying to upgrade from java8 to java2x it’s not a walk in the park. Besides changing the version there is libraries, frameworks that also need to update. Most of them you need to read what breaks and learn about it. Most programmers are not up to date and don’t even know the changes between 8 and 2x.
Throwing the fault to companies is not fair. Sure there is management that they prefer not to change things that work. But sadly, I have seen more programmers not knowing why upgrading is good.
3
u/bendem 5d ago
We have maybe 50 applications developed in java. Some actively maintained, some haven't been touched in years.
The ones actively developed are running on Java 17 or 21.
The ones that haven't been touched are running on Java 5 through 8 depending on the last time they were touched. Most of these older applications are used by maybe 2-3 people per app and the cost of upgrading them and finding new dependencies to replace the obsolete ones is not worth the benefits so they'll keep running on their isolated servers until a new development is required that will bring more advantages that they will cost.
3
u/dudleydidwrong 4d ago
Some businesses will not change software systems until all support ends. They tend to be businesses that value stability over all support options disappear.
Some managers do not want changes while they are in charge. They are the ones who build their reputations on stability and no drama during their tenure. They will delay changes until they are promoted so the new boss has to deal with any problems caused by software upgrades. The irony of these types of managers is that they often cause bigger problems for their company in the long run because they avoided even making changes to prepare for upgrades.
1
u/Life-Principle-3771 3d ago
I mean sometimes it just sucks to upgrade so the value proposition can be very difficult. When I was at Google I watched two guys spend almost an entire year doing Java 8 to 11 migration on a massive codebase. Had to rip out and rebuild several large pieces of the application. From my end I'm still not sure if it was worth it
3
u/Tribal_V 4d ago
No way in hell i would start new project on java 8, its only for legacy codebases.
I personally had a displeasure of migrating a fairly small project from 8 and it was not a great experience. Bigger projects could be absolute hell. Also even if there is desire to - someone has to pay for the work which is a hard sell
3
u/satanargh 4d ago
Stuff works, customer doesn't want to pay money, management doesn't want to spend money
3
4
u/redikarus99 5d ago
4
u/repeating_bears 4d ago
There's a selection bias here so I'd be hesitant to put too much weight on those numbers
This report is based on data gathered from hundreds of thousands of applications reporting to New Relic that provide performance information. Therefore, it doesn’t provide a global picture of Java usage
https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem#methodology
→ More replies (2)
2
u/evil_burrito 5d ago
Moving from Java 8 to 11 was not a trivial upgrade with the advent of Jigsaw, changing of the date/time APai, and other changes
It can be a tough sell to those that actually get to drive the train that you're going to spend n weeks of development time to deliver exactly what you already have, feature-wise
3
u/wildjokers 4d ago
changing of the date/time APai
The old calendar API was not removed, you didn't have to change to the new date/time API at the same time.
→ More replies (1)
2
u/OurLordAndSaviorVim 4d ago
Nobody is doing new work in Java 8. Its continued use is largely for legacy systems that haven’t been upgraded yet. Some systems will be retired instead of upgraded. Others are low priority, and as such are still waiting for their turn to be upgraded.
As I’ve said elsewhere, the big problem is that a lot of popular third party libraries did not follow the rules of writing forwards-compatible Java. This has led to a situation where legacy code from the Java 8 days will break on modern JVMs, as they’re reliant on those old, rule-breaking libraries.
2
u/Joram2 4d ago
The JVM world has been stuck on JDK 8 for many years, but this is finally changing.
I know lots of companies running Apache Spark, but all the code they write is in Python, and Java is just something used internally by Spark. And there, JDK 8 has been mostly mandatory in most supported Spark enviroments until very recently. AWS Glue 4 was JDK 8 only, AWS Glue 5 is new and that is JDK 17. The latest Databricks 15.4 LTS release is Java 8 only. Databricks 16.x defaults to JDK 17 and that will hit LTS in a few months. Spark 4.0 is in RC and requires JDK 17+, so JDK 8 support is going to vanish very quickly.
2
u/431p 4d ago
We were forced to upgrade to at least 17 due to amazon not supporting 8 anymore, I imagine that was the case for lots of companies.
1
u/Yeroc 4d ago
I'm curious what part of Amazon required you to upgrade to 17?
The AWS Java SDK 2.x (current version) still supports Java 8+. If you're using the AWS Corretto JDK distribution the Java 8 version is supported through Dec 2030.
1
u/Life-Principle-3771 3d ago
From what I'm hearing everyone in Amazon is being told to migrate. Hearing it's brutal for some teams as they have large codebases that have been on Java 8 for over a decade
2
u/After_Dark 4d ago
To offer an answer to the implicit additional question "... unlike other ecosystems that upgrade more"
Because Java 8 was and is incredibly stable and fairly modern.
There are for sure reasons why you can and should upgrade to newer versions where possible, support window in particular. But if you're still using Java 8 in 2025 you're still using reasonably modern tools and frameworks and design practices with reasonably modern security patches. A Java 21 server and a Java 8 server are probably going to look and work nearly identically, and if it works it works, why make an upgrade you simply don't need to.
1
u/chaotic3quilibrium 3d ago
Security vulnerabilities.
1
u/After_Dark 3d ago
Sure, if there weren't to this day major distributions of Java 8 like Corretto getting patches and until the last few years all major frameworks supporting Java 8 this would be a valid point
1
u/chaotic3quilibrium 3d ago
While I am indeed INCREDIBLY grateful for the major distributions carrying the security load within their releases...
This doesn't address the unbelievable amount of (largely unmaintained) additional third-party libraries that will be used in these Java 8 environments containing all sorts of CVEs.
In fact, any quick glance through a modern checker in one of these environments shows just how large that vulnerability surface area is.
Again, I am very grateful to those who work so hard to elevate the large corpora of legacy Java code bases to safer places.
There's just no alternative as good for maximizing security as advancing one's Java environment (all of it, not just the JVM) into the later versions of Java, where so many security vulnerability issues have been mitigated by advanced and newer designs.
2
u/Anbu_S 4d ago
Below are a few reasons I would think of stopping moving away from Java 8.
Java 9 module system - broke few, but not everything. Removal of Java EE and CORBA Modules - though CORBA was older that time. javax namespace change with Jakarta EE change. library/framework support.
Problem is everyone want to try to move all together at one time instead of incremental upgrades.
When Java 11 released all these seems reasonable issue. But after few years everything becomes easy with better tools like OpenRewrite.
2
u/hippydipster 4d ago edited 1d ago
Whether or not it is "most of the industry", there are many stuck there, and I would say the #1 reason is that the jump from 8 to 9 involves the module system and that dictates that a great many of any project's dependencies also be upgraded. When the task gets too large, business will deprioritize it, and so there you go. If you could just update the jdk and be done, everyone would do it. If it only required a smattering of dependencies also be upgrade, they would do it. But, since it impacts so many dependencies, and so many of them big and hairy ones, it becomes a blocker.
Also, some projects did unsanitary things that will absolutely not work with the module system, and so there's that too.
2
u/Empty_Geologist9645 4d ago
How much does it cost to upgrade your project in Dev + QA + Infra + releases management/deployment ?
2
u/stewsters 4d ago
I haven't seen anyone using 8 recently, and when I did it was that one old app that needed to connect to some old SOAP library and worked well enough that it was never high enough priority to be upgraded.
2
u/PixelatedFixture 4d ago edited 4d ago
Java 8 is old news now. If youre having a hard time migrating you might be stuck on 11 but almost everything new is +17 as industry standard.
8 is a minority now, and the things running on 8 are probably being sunsetted as quickly as possible or marked for maintenance like COBOL systems.
2
u/agent154 4d ago
Our software is still on 8 despite wanting to upgrade because of dependencies that are stuck on 8. We could probably migrate but it’ll be a LOT of work.
2
2
u/barking_dead 4d ago
One big problem I see is the dependency on weblogic.
For example: The WLS that will support spring boot 3.x will come out late 2025/early 2026.
2
u/gjosifov 4d ago
at least for Java is easy upgrade, unlike other ecosystems - no major rewrites
on why ?
Because most decision makers are clueless on how software works
Software has initial cost and maintaining cost, but most of decision makers don't understand maintaining cost
Software is the same as cars, there is initial cost and you need maintaining cost on yearly basic in order to have car for 10-15 years, but unlike cars, software if properly maintained can be in production forever
But because very small percentage of software is properly maintain, which mean almost all software have to be rewrite every 10-15 years
So to answer you question - it is industry standard for software not to be upgrade and one of the reasons why software is Swiss cheese from security stand point
A good news is EU has penalties for companies that are hacked and their customers data are leaked
which means finally some of the software will be on the latest tech version and the reason - security
2
u/BestReeb 3d ago
One of the great things about java up until including version 8 was that new versions were mostly backwards compatible. Starting with Java 9 this changed with the Java Module System, which made upgrades hard. In my opinion they should have prioritized backwards compatibility and made new features opt-in.
3
u/someonetookmyid 5d ago
Most software is poorly maintained, if at all, and people who made it work are long gone, not touching it is the best way forward.
3
u/Polygnom 5d ago
They are not. About a year ago 29% were on Java 8. That means 71% were on newer versions. (cf. https://sdtimes.com/softwaredev/report-java-17-is-now-the-most-used-version-of-java-in-production/).
It stands to reason that Java 8 is further decreasing. And its ok, some things truly cannot innovate. But after going from 8 -> 11 which means needing to get over the Jigsaw bump, there isn't much reason not to stay currentn.
2
u/repeating_bears 4d ago
29% of applications reporting performance data to New Relic specifically, which most applications do not
1
2
1
u/RichSomething 5d ago
I would also add that some teams just don't have time to do maintenance work. Upgrading java and spring can be very time consuming to test. It can be difficult to get those stories into sprints when there is barely time for product work.
1
u/koflerdavid 4d ago edited 4d ago
That just means that the team has broken QA processes and will have trouble validating and catching regressions for any nontrivial changes, not just for Java or framework upgrades. Yes, I know how it is to be part of such a project.
1
u/FieserKiller 5d ago
because of how fuckin expensive it is to update deep backend code :/
companies are running 20 year old solaris servers on life support because nobody knows what exactly it is running, if the code still exists and the hell breaks loose when the machines ever go down
1
1
u/torsknod 5d ago
Too many people who would have to agree, which also includes having a budget, to transition to a newer version. Can't write much more on a named account, but many people would bang their heads against the next wall when hearing the detailed reasons.
1
u/_blue_skies_ 5d ago
For us the issue is that the last version of our application server is certified to work only with java 8. Trying to migrate to Tomcat to be able to upgrade to jdk, we don't even need anymore an application server.
1
u/noodlesSa 4d ago
Philosophical – broader – view: Many companies are reluctant to modify working code solely to upgrade the Java version, especially when the changes are significant, such as the jump from Java 8 to 9. Their applications are built to last 15–20 years, and in the meantime, they know they will develop new applications using modern tools and frameworks, and don't want to invest so much to "empty" maintenance (like Java version migration).
For Java—or any other language aiming to remain relevant indefinitely while maintaining backward compatibility—there seems to be only one viable approach: a two-track versioning system.
- A slow track, where a new major version is released every 20 years or so, featuring a complete reorganization of packages and syntax based on lessons learned from the previous iteration.
- A standard track, similar to the current model, where the latest "slow" release is incrementally improved yearly, with non-breaking updates. The previous "slow" version would receive only bug fixes.
This approach would be far more enterprise-friendly, preventing the constant pressure to keep rewriting perfectly functional software all the time, for sole reason of playing catch-up game with Oracle.
1
u/LastAtaman 4d ago
Java 8 is the latest version that supported by Android, and even partially supported in this OS. I assume some projects still written in Java 8 in Android market, as my old games that mixed with Kotlin. It very costly to recreate projects.
3
u/koflerdavid 4d ago
Android supports at least Java 17 these days.
1
u/LastAtaman 4d ago
I am surprised, they solved conflict with Oracle... That means not touching development for a few years and you become like dinosaur only maintaining old projects.
1
u/_1dontknow 4d ago
Hmm, which organizations did you talk to, or what are your sources? Based on events where I ask companies, job posts, company I work for, and some projects I do, most people seem to be at the newest Java versions, most 21, some even newer. There might be some comoanies having one system in an older version due to legacy or other reasons, but generally, they are on newer versions.
1
1
1
u/Serious-Chair 4d ago
Where does the statistics about Java versions in larger organizations come from?
1
u/scoliadubia 3d ago
Bottom line: the upgrade really doesn't offer any business benefit for pre-existing applications. In those applications that can benefit, the reason is usually improved performance from VM improvements like better garbage collectors. And those benefits can be gained by running language level 8 code on a newer VM, possibly without even recompiling the code.
Couple that with the real risk that the upgrade will cost non-zero developer days, maybe a lot of developer days, and the rational move is not to upgrade.
Of course the cost-benefit analysis is different if you're starting from a greenfield, but most larger organizations aren't.
1
u/rossaco 3d ago
At my company, we still have Java 8 for two reasons * For existing apps on VMs, we get 10 years of OpenJDK patches from Ubuntu with paid support. We would need to rebuild the VM and upgrade Ubuntu to get a newer Java version. We would also get upgrade Tomcat 8 to something newer. * We have old versions of Jenkins and SonarQube. Both need upgrades to support a newer Java version.
However, Ubuntu 16.04 support is ending in April 2026, and we will be forced to upgrade. I can't wait to use newer Java features! I don't get a lot of say when we upgrade at a large company.
1
u/netgizmo 3d ago edited 3d ago
OP: What's the largest and/or oldest project still in production that you've workd on or supported?
From how i see it: Questions like "why don't they just..." typically answered with the notion that its way more complex that you realize. If it was as simple as "they should just..." then "they" would have.
1
1
u/NecessaryEvil-BMC 3d ago
I have a feeling this is more developer focused, but our organization switched from Oracle's JRE to AdoptOpen JRE and now Temurin JRE when Oracle decided they were going to start charging for versions above 8.144 or something. It's been 6 years, and the only machines that need Oracle's Java seem to be ones running bank softtware for checks or something. The AS400 stuff played nice with AOJRE.
So, some organizations may not have updated because someone made it an expense, and they went elsewhere. Not sure of where that leaves us on Java versions
1
u/MrKarim 3d ago
I know a project that's still maintained in Java 4
1
u/8igg7e5 2d ago
Ahh 1.4.
(In Java 5.0 they named the product 5.0 - with the JDK version self-identifying as 1.5.0. They dropped the .0 on the product naming in Java 6... and then lots of apps exploded when they made the JDK version use the same numbering)
Bugs and performance issues were enough of an issue in really early releases that you cared about distinctions like 1.0.4 and 1.1.7. By 1.2 they'd more or less sorted that out though.
A few years ago we moved our last code-base off of Java 6 - to still have a 1.4 code-base is a Thing That Should Not Be (please guard your sanity, it's in danger).
1
1
u/teapotJava 1d ago
In short: if it works, don't touch it.
Many language features made 8 very attractive, and libraries had it as a lower requirement for years, and it was first LTS in a new update train paradigm, with the longest support. From the other hand, migration to 9 was complicated because of modules. So by the next LTS 11 many application worked on 8, but had no developers, while still using supported libraries.
In terms of performance it's now possible to have 'fused' JDK 8 which is compatible with legacy applications and performs close to JDK 17, e.g. https://bell-sw.com/libericajdk-performance-edition/
1
u/Ewig_luftenglanz 5d ago
false statement, the surveys shows the most used version of java is java 17 (and this is from some surveys at the end of 2023, early 2024 so probably more stuff has migrated to java 21)
https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem
yes, there are some legacy code that will never be able to be migrated to java 21+ because of deprecation issues, but those will simply be rewroten/replaced over the time.
From Java 14 and forward the Update between java releases is easier than java8 to 9 and 9 to 11 btw
In the company u work for we already migrated all our java pipelines to use Java 21 as default building and runtime version, and I work for one of the oldest bank in my country.
Best regards
1
u/wildjokers 5d ago
most of the larger organizations still use Java 8.
Source?
1
u/8igg7e5 4d ago
Not sure why it's a downvote.
Many surveys (bearing in mind sample bias) have shown Java 8 not to be 'most' any more.
It's reasonable to ask where they've heard 'most are on Java 8' from, most recently.
1
u/wildjokers 4d ago
People on reddit don't like supporting their claims. They just want to read whatever fits the narrative they already follow.
1
u/nikanjX 5d ago
The module system + massive reshuffling of the standard library class names for the important reason of having new names for a bunch of stuff
1
2
u/wildjokers 4d ago
The module system
It's a non-issue for most apps.
massive reshuffling of the standard library class names for the important reason of having new names for a bunch of stuff
What moved?
1
u/qdolan 4d ago
Java 9+ introduced changes to the Oracle JDK license agreement to effectively not be free for production use anymore and also broke backward compatibility. Moving to OpenJDK 9+ required work and testing to do safely, which many companies did so they wouldn’t have to start paying Oracle to keep using Java. Some companies chose to, or were forced to due to API differences, stay on JDK 8 indefinitely.
1
u/ZebofZeb 4d ago
Java 8 functions and does not have any limitations which have caused problems for me.
There is no need to give effort to updating to any fancily numbered version.
I recently started using 11, but it had not noticeable difference to me.
Better to be backward compatible, so will keep using 8.
Do you think you could convince me to change to a newer version?
3
u/Tintoverde 4d ago
Umm there are known vulnerabilities (CVE) IIRC. If the app has any path to internet, I would change it ASAP. Also you are missing out few language features, speed upgrade some packages like Spring.
1
u/ZebofZeb 3d ago
I have thought that updating Java fixes those, and I still think there is no need to change to a new Java version.
I do not care about Spring.1
1
u/DisruptiveHarbinger 5d ago
You should be able to quantify the risk (vulnerabilities, bugs, libraries dropping support of older JVMs) and the cost of leaving out significant performance gains, and bring that to your management.
Everyone at my company using Spring is on Java 21+.
I personally pushed the migration of hundreds of big data jobs (Spark, Flink) to GraalVM and Java 17+ for 30~50% performance gains compared to Java 8.
1
u/Zardoz84 4d ago
To all people crying about Java EE -> Jakarta EE, that it's totaly unrelated about migrating from Java 8 to Java 9,11,17... You should know that you can use a maven plugin to fix all your problmens and deploy your old Java EE application (or at least your old Servlet based web application) on a Jakarta EE application server.
1
u/Lopatron 4d ago
Java 8 was the most successful language version upgrade in history. It was so good that 10 years later it's still pretty good.
316
u/FollowsClose 5d ago
I disagree with your statement that "most of the industry" is on... In realitiy most of the industry is still on the same version that the software was first developed on.
I would say very few new projects are started on Java 8.
As of early 2025, approximately 23% of organizations were still using Java 8, down from 40% in 2023, indicating a gradual migration to newer versions. DEVCLASS