# Java 17 Runs Out of Premier Support This Month

Java 17's Premier Support ends this month, and fifteen years in enterprise Java codebases taught me that date is almost never why a company actually upgrades.


Java 17’s Premier Support runs out on 30 September 2026, according to endoflife.date, and in fifteen years of walking into large Java codebases I have never once seen a date like that be the actual reason a company moved.
I spent that time as an enterprise Java consultant, in places like a bank’s core ledger, an airline’s distribution system, a public administration’s case management platform. Every one of them had a support calendar pinned to a wall or a wiki page somewhere. And every one of them upgraded on its own schedule anyway, usually years after the calendar said to, and for reasons the calendar never mentioned.
The clock everyone quotes and nobody follows Oracle has released a new LTS every two years since Java 17: 21 in 2023, 25 in September 2025. Java 21 stays under Premier Support until September 2028. Java 25 runs to September 2030. So the cadence itself is not the problem. Two years is plenty of runway if runway is all you need.
It is not all you need. A version bump is a straightforward technical task. An upgrade, in an organisation that has been running the same system for a decade, is a political and archaeological one, and those are the two things a support-lifecycle chart cannot show you.
What actually blocks the move Nobody has ever told me “we can’t upgrade because of a missing language feature.” Not once. What blocks the move is always some specific, nameable thing that has nothing to do with Java 17 versus Java 21:
A dependency that has not published a release since 2019, pinned in the build because the newer major version renamed half its API. A build server that everyone is afraid to touch, because the person who set it up left the company and the configuration lives entirely in their head, which also left the company. An internal framework, usually a homegrown dependency-injection layer or an ORM wrapper written before the team standardised on anything mainstream, with no tests and no documentation and one very tired engineer who still remembers why it works. In a regulated shop, a bank or a public administration especially, there is a fourth thing stacked on top of all this: a change has to clear an approval process built for risk, not for maintenance, and “we upgraded the JVM” reads to that process exactly the same as “we changed how payments get calculated,” because the process cannot tell the two apart and is not built to try. So the upgrade waits in the same queue as every change that might touch production, behind whatever the business actually asked for this quarter, and the queue does not care what Oracle’s support calendar says.
Any one of those turns a two-week version bump into a six-month project with a budget line and a steering committee. “Just upgrade” is advice from someone who has never had to explain to a finance department why software that worked fine yesterday needs six months and a team to keep working fine tomorrow. I have given that advice myself, early on, and I was wrong every time I gave it without first asking who owns the build.
The honest version of the advice is duller: find the thing nobody wants to touch, budget for that specifically, and treat the language upgrade as the easy part you do once the scary part is out of the way. It usually is the easy part. That is exactly why it is never the blocker.
Tooling does not wait for the organisation While all that sits on someone’s backlog, the tools race ahead regardless. IntelliJ IDEA 2026.2 arrived in July 2026 with support for Java 27, a version that will not even be an LTS, and for Kotlin 2.4. Kotlin 2.4.0 itself came out on 3 June 2026 with stable context parameters and dropped its old K1 compiler frontend entirely. None of that waits for the bank running Java 8 in a container somewhere, and none of it is meant to. The IDE and the compiler ecosystem move on a completely different clock than the systems they are pointed at, and most of the time that gap is invisible because most developers open the IDE on a laptop that has nothing to do with the production JVM three network hops away.
I build IDE plugins for a living now, at Ilscipio, which puts me on the tooling side of that gap more often than the enterprise side these days. It is a strange vantage point. I get to watch a plugin team support a language version that will be unusual to see in production for years, while knowing exactly what kind of decade-old build server is still deciding, somewhere, whether any of that matters yet.
The version number rolling over on 30 September is not the story. The story is whichever line item on somebody’s risk register has been sitting there since before I got involved, and now has a deadline stapled to it whether anyone asked for one or not.