Java is dead again?

Every so often the technology press discovers that Java is about to die. This is not a new phenomenon and I've tried to address it in the past. If you’ve been around long enough, you begin to notice that Java appears to die on a fairly regular schedule, usually coinciding with the rise of whatever new language has captured the industry’s attention that year. Recently those candidates have often been Rust and Python. Both are excellent languages with strong ecosystems and very real strengths. They also happen to be fashionable, which inevitably leads to a certain amount of enthusiastic commentary about what they might replace.

The difficulty with these narratives is not that they’re entirely wrong, it’s that they tend to assume a level of universality that rarely exists in practice. Which brings me to another passion of mine: physics.

If you've done any physics classes or have even a general interest in it, you've probably come across Sir Isaac Newton’s formulation of classical mechanics. Newtonian physics gives us a set of equations that describe how objects move and interact at everyday scales. Whether it's cars, bridges, rockets or cricket balls, Newton does a remarkably good job of modelling them. However, as you delver further into physics classes or books, you'll learn that Newton’s model isn’t the whole story: at very small scales, the behaviour of particles is better described by Quantum Mechanics, while at extremely high speeds and large gravitational fields we need General Relativity.

However, this discovery doesn’t lead physicists to declare Newton obsolete. Instead, they do something rather more practical: they use the model that works best for the problem they’re trying to solve: if you’re designing a bridge, you probably don’t need a quantum mechanical treatment of the steel atoms!

OK so how is this relevant to Java? Well programming languages are tools and tools tend to be well suited to particular types of problems. None are universally optimal. For example, Python is widely appreciated for its rapid development cycle, readability and strong ecosystem in data science and machine learning. Rust brings impressive guarantees around memory safety and control over low-level system behaviour. Java, despite its periodic obituaries, continues to offer a mature ecosystem, portability and a runtime environment that has been tuned for large-scale enterprise systems for decades.

None of these attributes automatically invalidate the others. The reality is that modern systems frequently involve multiple languages and platforms. A machine-learning pipeline might be written largely in Python, a performance-sensitive component in Rust and the surrounding business services in Java. (Note, I'm not trying to suggest that high performance and Java are mutually exclusive, because they're not; this is an example.)

That arrangement isn’t a failure of architectural purity. It’s simply the result of using different tools where they make sense.

One of the more interesting transitions in a developer’s career is the moment when the question shifts from: “What’s the best technology?” to something slightly more nuanced: “What’s the best technology for this problem?” Architects tend to accumulate tools over time, languages, frameworks, design patterns and operational practices. The goal isn’t to become ideologically attached to any one of them, but to understand their capabilities and limitations.

A hammer is excellent for driving nails. It’s less effective when asked to tighten a screw. Programming languages behave in roughly the same way and this is where experience becomes important. Every technology carries trade-offs:

• performance characteristics.
• operational complexity.
• ecosystem maturity.
• developer productivity.
• long-term maintainability.

Ignoring those trade-offs usually leads to disappointing outcomes, whereas understanding them allows developers to design systems that deliver what customers actually need rather than what happens to be fashionable at the moment.

If you look beyond headlines about the “death” of particular languages, the industry tends to behave in a far more pragmatic way. Successful systems are rarely built around a single universal tool. Instead they evolve into ecosystems of components, each selected because it solves a particular problem well and in that sense, software engineering looks a lot like physics: Newton still has his place and quantum mechanics has its own domain. Both are useful, provided you remember which problem you’re trying to solve.

And if Java continues to die every few years while quietly running a large portion of the world’s infrastructure in the meantime, that may simply be another example of the same principle.