Contents
SECURE CODING & THE JAVA PLATFORM
▪️ Security in the Age of Java 25: New Language Tools for Safer Code
▪️ Top Security Flaws Hiding in Your Code Right Now – and How to Fix Them
API & FRAMEWORKSSECURITY
▪️Mastering API Security in Java: OWASP Best Practices
▪️ The Security Innovations in Vaadin 25.2
SOFTWARE SUPPLY CHAIN & SBOM
▪️Sharing SBOMs Securely Without Giving Too Much Away
▪️ SBOM for Java Developers: What Does It Really Give Me Day-to-Day?
▪️ From Breaches to Blackouts: The Human Consequences of Software Supply Chain Attacks
▪️ The Shai-Hulud NPM Worm: When Supply Chains Bite Back
▪️ The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale
LEGACY & MODERNISATION RISK
▪️Why Struts 1.3 Still Matters in 2026
▪️ The Jakarta Cliff: Why Modern Java Leaves Struts 1 Behind
FORENSICS & REVERSE ENGINEERING
▪️Code at Court – Java as Evidence
▪️ AI-Driven Reverse Engineering of Java Applications
▪️ Reverse Engineering Java: Backtracking Native Crashes
Details
Page count: 107
Authors: Mohammad-Ali A’râbi, Muaath Bin Ali, Mihaela Gheorghe-Roman, Jonathan Lopez, Steve Poole, Gireesh Punathil, Sven Ruppert, Martin Toshev, Stefan Wagenpfeil, Ravali Yatham
Editorial
Security Is Not a Feature — It Is a Discipline
Security has quietly moved from the edge of our work to its very center. For a long time it was treated as something added late: a review before release, a scanner in the pipeline, a checkbox on a compliance form. That era is over. The systems we build today are connected to everything, assembled from thousands of third-party components, and increasingly extended by AI that writes code faster than any human can review it. In that world, security is no longer a feature you bolt on. It is a discipline that runs through every line of code, every dependency, and every deployment decision.
This special edition brings together the strongest security writing from recent JAVAPRO issues into a single, focused collection. Read end to end, the articles tell a coherent story that moves from the language itself, outward through your APIs and frameworks, and all the way to the software supply chain that now defines our collective attack surface.
We begin where every Java developer has the most direct control: the language. Modern Java gives us real tools for safer code—immutability, sealed types, pattern matching, and a modernized cryptography stack—and knowing how to reach for them changes the security posture of an application before a single external library is involved. From there we turn to the boundary where most breaches actually happen: your APIs. OWASP best practices for Java, and a practical look at the security flaws hiding in ordinary code right now, show how much risk lives in the code we already own and how methodically it can be found and fixed.
Frameworks carry much of this weight for us, and it matters how they do it. A close look at the security innovations in modern Vaadin demonstrates how a framework can make the secure path the default path—and how sharing a Software Bill of Materials responsibly lets us be transparent about what we ship without handing attackers a map.
Then the ground shifts beneath us. The final articles confront the reality that our biggest exposure is no longer only our own code, but everything we depend on. The human consequences of software supply chain attacks, the mechanics of a self-replicating npm worm, and a memorable fable of the lessons hidden inside a single JAR file all drive home the same point: trust in the supply chain must be earned, verified, and continuously re-verified.
Beyond the core of secure coding, this edition widens the lens with a set of closely related perspectives. We look at what happens when Java code becomes evidence in a courtroom, where software forensics, Git history, and an SBOM turn into instruments of proof. We confront the uncomfortable security reality of legacy: why a framework like Struts 1, long past its end of life, still runs in production, and why the Jakarta cliff makes standing still a growing risk. And we turn the attacker’s own instruments around—using AI-driven reverse engineering and native-crash backtracking to understand exactly what our compiled artifacts give away. Security does not end at the code we write today; it extends to the code we inherit, the code we ship, and the code others can read back out of it.
Taken together, these articles share one message. Security is not a specialist’s concern to be delegated away. It is an engineering discipline that every Java developer already has the means to practice—in the language, in the API boundary, in the framework, and in the way we consume and share dependencies. The threats will keep evolving. Our discipline has to evolve with them.
A very special thanks goes to all the authors of this issue. By generously sharing their hard-won security expertise with the Java community, they help make the entire ecosystem safer for everyone who builds on it.
Stay curious, stay skeptical, and enjoy this issue.
