▶ YouTube Summaries

← All summaries
fknight#▶ Watch

Why companies stay on Java 8, and why staying now costs more than leaving

2026-10-14 Wed ⏱ 17 min fknight

Forrest explains why roughly one in four production Java code bases is still on Java 8, and gives developers arguments to take to leadership. He names three causes: breaking JDK changes, a compounding framework and namespace migration, and the fact that Java 8 support keeps getting extended. He then lists what staying costs: performance, patch fees and ecosystem drop-off. His main point is that automated migration recipes and AI agents have cut the cost of upgrading, so moving off Java 8 is now the cheap option. He says it is not exhaustive and does not claim that everyone must leave Java 8.

Sponsor: WorkOS

  • AuthKit-based authorization for MCP servers: paste your AuthKit domain and the server becomes an OAuth 2.1 resource server with PKCE, resource indicators and scoped tool permissions.
  • The server only verifies tokens and serves a metadata endpoint. Dynamic client registration and consent are handled by AuthKit, and WorkOS Connect works as middleware over an existing login system.

The problem

  • Every Java video gets a comment that "my company will never leave Java 8". About 25% of production Java is still on 8.
  • Top advice from a commenter: find any reason that saves money.
  • It is not just laziness or "if it works, don't touch it". Netflix was mostly on Java 8 until 2023, nine years after release. Their Java 8 to 17 data is the best case study he has seen.

Why shops got stuck

  • JDK breakage:
  • Java 9 modules strongly encapsulated internals. Libraries that used reflection into sun.misc or com.sun (Mockito, Lombok, Hibernate, Spring proxies) broke or warned, and rt.jar disappeared, which broke classpath scanners.
  • Java 11 removed APIs such as JAXB, so XML-mapping code stopped compiling until you added the libraries from Maven Central yourself.
  • Everything worked on 8, so the upgrade kept being pushed off.
  • Compounding barrier:
  • Spring Boot 3.0 (Nov 2022) requires Java 17, so Java 8 shops are also stuck on Spring Boot 2.7.
  • Upgrading now means doing the JDK, framework and javax to jakarta namespace migrations all at once.
  • The namespace change happened because Oracle handed Java EE to the Eclipse Foundation in 2017 but kept the trademark. Negotiations failed in May 2019, so every API had to be renamed to Jakarta.
  • Amazon said Java 8 to 17 averaged 50 developer days per app.
  • Java 8 will not die:
  • Oracle shipped Java 8 update 503 in August, outside the regular patch cycle.
  • Oracle commercial support moved from March 2025 to end of 2030, followed by "sustaining support" with an indefinite end date.
  • Oracle says it extends support based on customer adoption, so the more people stay on 8, the longer it lasts.
  • Spring Boot 2.7 commercial support moved from Feb 2025 to Aug 2025, then end of 2026, and is now June 2029.

Fair exceptions

  • Telco on Spring 2.7 and Java 11 serving 40 million customers a month, where the risk of a failed migration is higher. In the description he adds that at that scale such a company would benefit most from modern Java.
  • WebSphere versions that do not run anything newer, so the JDK choice is not theirs.
  • Dutch municipality app hosted by an outside contractor who does not want to upgrade, with no budget to force it.

What staying costs

  • Quote from Java champion Johan Vos: moving has a small immediate cost, while staying has a huge, potentially catastrophic but not immediate one.
  • Performance:
  • Netflix saw about 20% less CPU moving from Java 8 to 17 with no code changes, thanks to G1 improvements. Paul Baker said at QCon that the number was real, and that is how it got funded.
  • Java 25 compact object headers give 22% less heap and 8% less CPU on SPECjbb from one JVM flag.
  • AWS says its Java 17 upgrade saves $260 million a year through fewer hosts. Smaller shops will see a smaller effect.
  • Money:
  • Spring Boot 2.7 on Spring Framework 5.3 is out of free support, so security patches are paid.
  • Ecosystem:
  • Dates for Java 8 and Spring 2.7 keep slipping, but libraries do not follow.
  • Kafka 4.0 requires Java 17, and its reason was that dependencies such as Jetty 10 might drop Java 8 first.
  • JUnit 6 also requires Java 17.

What changed: migration is now cheap

  • OpenRewrite has composite recipes for every hop (8, 11, 17, 21, 25) and for Spring Boot 2 to 3. They re-add JAXB and JAX-WS, replace JDK internals calls with supported APIs, and rewrite javax imports to jakarta. You add the Maven plugin, run it and review the diff.
  • New is AI agents wrapping the recipes: take the diff, run the build, read failures, fix, and repeat until green.
  • GitHub has a Java modernization agent. Amazon built one into Amazon Q, which cut 50 developer days per app to a few hours.
  • Caveat: vendors are selling their tools, so those numbers are best cases.
  • Netflix is not selling dev tools. It used Claude Code running headless in batch to migrate about 3-4k services from Spring Boot 3 to 4. Baker said the agents beat their deterministic tooling.

The math for leadership

  • Old pitch: 50 dedicated developer days, everything else on hold, and a performance payoff that only matters at scale. Easy no.
  • New pitch:
  • Cost is hours at best, days or a couple of weeks at worst, and mostly automated in the background with checkpoints, so feature work is not paused.
  • Payoff is performance gains, no paid security patches, compatible libraries including ones that dropped Java 8, and no tracking of shifting end-of-life dates.
  • Conclusion: upgrading from Java 8 is now the cheap option and staying is the expensive one.
  • Remaining decisions: target 21 or 25, not 17, since premier support for 17 ended last month, and which migration tools to use.
  • He asks viewers for their reasons for staying and for migration stories.