Java’s Boring Work Is Not Free

Java devs are more likely to understand something the rest of the industry periodically forgets. That important software doesn’t disappear when it stops being fashionable. It keeps running.

The application might be old. The framework might be out of support. The build might be ugly. The deployment process might be half automation and half folklore. The original architects may have retired, changed careers, or become fractional consultants who charge by the line of COBOL code.

But the system still matters.

Java moves money. It checks eligibility. It prices risk. It reconciles accounts. It sends invoices. It manages identity. It talks to a database schema older than some of the developers maintaining it.

But Java is still modern, active, and evolving. The platform is healthier than people outside the ecosystem often realise. Having people turn their noses up at Java often rankles. But Java has a particular relationship with long-lived enterprise software. It’s good at being boring. It’s good at surviving. It’s good at becoming infrastructure.

That’s a strength. It’s also why Java teams are exposed to AI reallocation risk.

When an organisation pursues AI, the boring systems are rarely the first to be protected. The glamour budget goes elsewhere. The hiring premium goes elsewhere. The executive attention goes elsewhere. The “strategic” work becomes AI platforms, AI products, AI governance, AI data, and AI agents.

The old Java estate is expected to cope. Often, this is because the sheer importance of the application and the historical effort required to bring it to this reliable, resilient state have been overlooked. Reducing expenditure on systems like this is a common meme in any business. Which is sort of fine until it isn’t.

Enterprise Java systems aren’t fragile in a cartoon sense. They contain a lot of accumulated context.

Why is this still on JDK 8? Why does this service use that old version of Spring? Why is this authentication flow split across three filters and a custom interceptor? Why does this batch job require that locale setting? Why does the upgrade break only one customer in Singapore?

The answer is usually not “because developers are lazy”. The answer is history.

Customer commitments. Regulatory constraints. Vendor dependencies. Unsupported integrations. Operational windows. Unowned code. Test gaps. Incomplete documentation. A migration that was started, paused, restarted, rescoped, and absorbed into a wider platform programme nobody fully owns.

AI doesn’t remove that history. In fact, it’s hard for AI to even understand it. AI might help surface some of it, summarise it, generate code to move through it. But the judgement is still human.

That’s the new “Just Upgrade”. An AI model can suggest a Spring migration. It can’t know which customers depend on the old behaviour unless the organisation has captured that knowledge somewhere the model can access it. It can generate tests. It can’t tell you whether those tests encode the right business risk. It can rewrite an API call. It can’t decide whether the new semantics are acceptable under your audit obligations. It can explain a JDK deprecation. It can’t negotiate your operational freeze window.

AI can accelerate migration work. But migration was never just typing.

Migration is dependency management, runtime behaviour, operational validation, customer risk, release sequencing, security posture, and organisational memory.

That’s why maintenance is not free.

Cutting or repurposing the people who understand the estate is dangerous in ways that don’t show up immediately.

A senior engineer moved from a legacy payments platform to an AI initiative may not look like a headcount cut. But the system has lost knowledge, ownership, and judgement. A QA engineer moved into an AI product team may not look like a control failure. But the legacy regression model just lost someone who knew what mattered. An AppSec engineer stretched across AI agents and the old Java estate may still exist on the org chart. But the review queue has changed.

This is how existing applications become the risk sink for AI ambition. The organisation funded AI by borrowing from maintenance, security, QA, and operational resilience.

By removing institutional knowledge and reducing engineering expertise, even if by accident, organisations weaken their defences at a time when the opposite is needed.

I’ve said this multiple times already, but it’s worth repeating- well, repeatedly. Reducing investment in existing applications is a poor strategy. Those systems are going to become more active - at least from a security patch/maintenance POV than ever before. We’re moving fast into a world of legislation around the use of AI and, of course, about being more secure. This isn’t happening for the fun of it. This is in direct response to the rising levels of attacks - whether cybercrime or cyberwar related. We need applications to be more secure and developers to be more security-conscious. Weaponised AI is a real and current threat to our existing systems, and it’s growing exponentially.

All our assumptions about cyberattacks need to be rethought. The one certainty is that organisations will have to expect regular security maintenance to become a thing - even for so-called EOL components. Taking humans off the line at this point is a dangerous experiment. One I suspect is more likely to destroy an organisation than any threat theorised because the organisation doesn’t have an “AI story”

The Java ecosystem isn’t outside the software supply-chain attack surface. Maven Central is part of it. Build plugins, transitive dependencies, annotation processors, test frameworks, CI integrations, container images, IDE extensions, and AI coding tools all sit in or near the trust path.

Java has historically benefited from a more conservative culture than some faster-moving package ecosystems. That helps. It can also create complacency. Dependency confusion and typosquatting are not npm-only ideas. Sonatype’s 2025 malware figures explicitly span multiple ecosystems, including Maven Central (Sonatype).

A familiar-looking package name is not trust. A plausible README is not trust. A generated test suite is not trust. A green scanner is not trust. A convincing PR is not trust.

Trust comes from provenance, maintainer identity, repeatable builds, dependency policy, review discipline, and operational context.

The governance answer isn’t complicated.

No significant AI initiative should be approved without a clear statement of what it funds, whom it consumes, which systems lose attention, and which controls are preserved. If funding comes from reduced maintenance capacity, say so. If it assumes AI tooling offsets headcount loss, say so.

Companies scrutinise layoffs. They review vendor spend. They approve hiring plans. But internal mobility often happens as if it were operationally neutral.

Moving someone who understands the legacy identity system, the build pipeline, or the dependency nobody else wants to touch is not neutral.

Any material movement of senior engineers, maintainers, platform owners, QA specialists, or AppSec people into AI programmes needs a transfer-impact discussion.

Which systems lose coverage? Which review queues are affected? Which compliance obligations depend on those people? What backfill exists? “AI will make the remaining team more productive” is an assumption. It’s not a control.

Ring-fence the boring work. The JDK migration needs a plan. The Spring upgrade needs a plan. The old application server needs a plan. The unsupported dependency needs a plan. The cryptography defaults, TLS settings, logging libraries, serialisation risks, build plugins, container images, and deployment scripts all need owners.

Even if the organisation won’t staff that internally, it still needs a strategy.

External maintenance, platform modernisation programmes, managed migration, extended support contracts: these aren’t signs of failure. They’re ways of being clear about reality.

Pretending the risk disappeared because the AI roadmap got more exciting is the actual failure.

A poor AI programme measures how many developers use tools, how many prompts were run, and how many lines of code were generated.

A useful programme measures whether the system became safer, easier to maintain, easier to change, and easier to recover. Watch patch latency, dependency SLA breaches, unsupported component count, migration progress, rollback rates, production incidents, test coverage quality, review lead time, and the age of known exceptions.

If AI adoption rises and all those indicators deteriorate, the organisation hasn’t improved. It’s just used AI to break the business.

AI raises the value of engineering discipline.

If your architecture is clean, your tests are meaningful, your ownership is clear, your dependencies are understood, your build is reproducible, and your release process is boring, AI helps you move faster.

If your estate is a haunted mansion of old frameworks, implicit behaviour, tribal knowledge, and green dashboards nobody believes, AI won’t magically turn it into a platform. It’ll generate confident suggestions on top of uncertainty.

Java’s strength has always been boring reliability at scale. That boring reliability was never free. It came from compatibility work, maintenance work, test work, platform work, security work, documentation work, and the accumulated judgement of people who knew why the system behaved the way it did and understood, intimately, how to get the best out of the platform.

The risk in the current AI investment cycle is that organisations forget that.

They see the ship. They see the deadline. They see the fuel.

So they start burning the ship...

Maybe they make it. But when they arrive, they shouldn’t be surprised to find the ship needs rebuilding.