What You’ll Learn


This article is the first in a series that explores why Struts 1 still shows up (quietly but persistently) in enterprise systems in 2026, and what that means for teams trying to keep the lights on.

We look at:

  • The Discovery Effect: How stable, forgotten Struts apps resurface during audits, migrations, and security scans.
  • Where the Friction Really Is: The talent shortage, the tooling disconnect, and the Jakarta EE shift: all colliding to make legacy upkeep harder than it should be.
  • Modernisation Without the Fantasy: Why the rewrite-or-risk framing misleads teams, and how approaches like embedding Struts in Spring Boot create workable transition paths.
  • Buying Breathing Room: How extended support gives organisations time to avoid crisis-driven decision-making.

Rediscovery Day: When Struts Finds You

There’s a moment every long-established engineering organisation experiences eventually. Someone in security or infrastructure runs an inventory sweep, or tries to update a container image, and stumbles across a WAR file from another lifetime. It boots. It works. And sitting right in the middle of it is a struts-config.xml, exactly where you hoped it wouldn’t be.

This is how Struts 1 is often found. Not because anyone was looking for it, but because it had simply faded into the background, quietly ferrying user requests for a decade or more. It’s remarkable how often these systems still run perfectly well. Struts 1 powered the early enterprise web. It introduced structure where there was none and helped teams escape JSP soup and ad-hoc MVC patterns.

Struts 1 has earned its longevity.

A Framework Out of Time

But frameworks don’t live in isolation. They live inside platforms, and platforms change. Over time, Struts 1 became less of a framework and more of a geological layer in the architecture. Important for sure, functional, but increasingly out of sync with the world around it.

Part of that misalignment is talent. In 2007, you could post a job for Struts developers and get a stack of CVs by the end of the day. 

In 2026, you’d be lucky to find someone who has ever extended a RequestProcessor or can explain the lifecycle of an ActionForm without Googling it. 

Most of the engineers who built these systems have long since moved on to newer frameworks, new companies, or new careers. Struts hasn’t been taught in years. 

Your discovery hasn’t just exposed old code; you’ve just inherited a way of development, of design, even a development culture that no longer exists.

Tooling Moves On, Even If the Code Doesn’t

Modern IDEs, static analysis engines, security scanners, and observability tools are built around annotation-driven frameworks. They expect explicit mappings and clear call graphs. Code paths that can be traced without having to mentally index a decade of XML configurations. 

A Struts 1 application predates those norms. It’s not hostile to modern tooling, but it lives at its edges. Things that are intuitive in Spring feel obscure in Struts, not because Struts is poorly designed, but because it predates the conveniences we now take for granted.

Security follows the same pattern. The framework itself hasn’t seen updates since 2013, but the libraries it depends on have continued their own journeys. 

Some patched, some abandoned, some replaced, some left exactly as they were. 

In a modern environment, you’re expected to patch your dependencies, keep your runtime current, and update your container images. Struts 1 lives in an ecosystem where many of those things aren’t possible. You can mitigate, isolate, inspect, and contain, but you can’t fix the framework itself.

The Platform Marches Forward, With or Without You

The world has moved on. Now we talk about Jakarta EE, MicroProfile, and Spring Boot.  Containers no longer ship the old javax.* API that Struts relies on. 

You can keep your environment pinned to older Java and Tomcat versions, but you can’t move forward without directly addressing the compatibility gap. 

This is what makes Struts 1 feel less like a stable legacy system and more like something that resists the natural motion of everything around it. It works, but only if the world agrees not to change.

All of this creates a very particular kind of pressure. Teams know the system needs to be modernised. Security knows the framework can’t be easily patched. Infrastructure knows the container stack can’t be upgraded. Leadership knows the business relies on workflows buried deep inside Actions and Form beans nobody wants to touch. It’s not an urgent crisis, but it’s a quiet tension.  A sense that the world outside the framework is accelerating while the application itself stands still.

The Modernisation Myth: It’s Not Instant, It’s Not Easy

This is also where the conversation can easily become unhelpfully binary: either rewrite the system from scratch, or accept the risks. 

Reality is far more nuanced. Modernisation is absolutely possible ( and often necessary), but it isn’t instantaneous. Running Struts 1 inside Spring Boot, sharing sessions between old and new components, and migrating features by feature is a practical approach, but it requires engineering effort. It means handling classloaders carefully, navigating the javax/jakarta divide, and building foundations for the new system without destabilising the old one.

That’s the part often overlooked when people talk about transformation: even with the right strategy, modernisation takes time. 

Modernisation is complex: from initial analysis to building scaffolds to support strangler-fig patterns, to the thorny aspect of migrating safely, including how to replace the business logic no one has touched since 2011.  It all takes time. Because ultimately this isn’t a big switch, it’s an attempt to retire old workflows gracefully with the least impact possible.

Buying Time: The Unsung Part of Modernisation

And this is where companies like HeroDevs enter the conversation, not as a shortcut, but as a pressure valve. Sometimes the most important thing an organisation needs isn’t a migration plan, but breathing room. A way to keep the system secure enough while the business prepares for its next move. The question becomes more about buying a year rather than a month, and about stabilising a legacy application so it can be replaced on the organisation’s schedule rather than the platform’s. 

Modernisation carries risk, and not every system needs to be modernised immediately. Some need to run safely until they reach their natural end of life. 

Supporting that reality isn’t avoiding progress; it’s enabling it.

Walking the Corridor, Not the Cliff Edge

So yes. Struts 1 is a product of another era. It carries assumptions the modern ecosystem has outgrown, and it sits on a foundation that the platform has moved away from. But this isn’t a story about disaster or panic. It’s a story about alignment. About understanding where the framework fits in a world that has evolved dramatically around it. And about recognising that the path forward isn’t a cliff edge; it’s a corridor. One you can walk steadily, carefully, and, if needed, with support.

The following articles explore the most visible part of that corridor: the Jakarta transition and why modern containers no longer speak the same language as Struts 1. 

Hold on - it’s a bumpy ride.

Interested in Learning More?
Steve Poole is a speaker at JCON! This article explores why legacy frameworks like Struts 1.3 still matter in modern Java environments and what they can teach us about maintaining long-lived systems. His JCON session, “Engineering a Modern Java Platform”, continues that journey by showing how organizations can modernize large Java estates and navigate the challenges of upgrading to current JDK releases. If you can’t attend live, you can explore many JCON sessions online – definitely worth checking out!

This article is part of the JAVAPRO magazine issue:

Engineering Intelligence - Building Systems in the AI Age

Explore what engineering means in the AI age — beyond code generation and automation.
Gain insights into performance-critical Java systems, evolving architectures, and the responsibilities that come with building intelligent software.

Discover the edition →