Hey Peter, ask OpenClaw what Java looks like in 2026. It might surprise you both - JVM Weekly vol. 163

Rant Edition. Because sometimes AI-Bro narratives aren’t just annoying - they’re dangerously stupid. And I’m too tired for diplomacy, so I chose violence.

Feb 19, 2026

For those who’ve been living under a rock: Let’s start with the Hitchhiker Guide to the Vibe Coded Lobster galaxy.

Let’s start from the beginning, because I know not all of you follow Twitter — though I have to admit, right now it’s (gulp) probably the most interesting social media out there (which is more of a commentary on the state of online discourse in 2026 than a compliment).

OpenClaw (formerly Clawdbot, then Moltbot - because Anthropic’s lawyers called) is an open-source AI agent created by Peter Steinberger. The project exploded in January 2026, racked up over 180,000 GitHub stars, spawned MoltBook (a social network for AI agents only, which my mom recently asked me about 🤯), and Steinberger himself just announced he’s joining OpenAI to - and I quote - “build the next generation of personal agents.”

The whole story is fascinating. Peter previously sold his company PSPDFKit for well over $100 million, went through three years of therapy and ayahuasca (yes, really), launched 43 projects, 42 flopped, and the 43rd hit the bullseye. Steinberger openly admits: “I never read parts of the code I shipped” - because OpenClaw is largely vibe-coded.

If someone had told me a few years ago that this is what programming would look like in the third decade - I wouldn’t have believed it.

Though my own Token Anxiety shows me just how addictive this process can be.

And to be clear: I’m genuinely interested in OpenClaw myself. I even built a client for it running on Reachy Mini - an open-source humanoid robot from Pollen Robotics/Hugging Face - and hooking it up to OpenClaw was freaking fun. Reachy Mini is fantastic hardware at $299, with a Python SDK and Hugging Face integration - the perfect toy for someone who (like me) wrote their bachelor’s thesis on controlling a robotic arm with a Kinect.

But just because something is fun doesn’t mean it’s above criticism. And I’m not talking about OpenClaw here.

I’m talking about a tweet that triggered a wave of frustration in the JVM community. A tweet in which 300,000 lines of unaudited TypeScript are presented as proof that traditional enterprise is dead. A tweet racking up hundreds of thousands of views, amplifying a narrative that everyone recruiting Java developers is already fighting.

So let’s talk about what actually lies behind that narrative. From both sides.

Let’s start with facts, because anyone can rant with emotions. Ranting with receipts - that’s a different league.

OpenClaw as an idea is fascinating. OpenClaw as a production system is a security disaster documented by at least five independent organizations:

CVE-2026-25253 (CVSS 8.8) - one-click RCE. The Control UI trusted gatewayUrl from query strings without validation and sent auth tokens over WebSocket. Clicking a single link = full instance compromise. Exploitable even on localhost.
Cisco AI Defense tested the “What Would Elon Do?” skill - 9 vulnerabilities, 2 critical. Silent data exfiltration and prompt injection bypassing safety guidelines. Their verdict, verbatim: “From a security perspective, it’s an absolute nightmare.”
Snyk ToxicSkills - the first comprehensive ecosystem audit: 3,984 skills, 36% contain prompt injection, 341 malicious, including 335 installing Atomic Stealer on macOS. 76 confirmed credential-stealing payloads.
Moltbook leak - misconfigured Supabase instance: 1.5 million API tokens, 35,000 email addresses, private messages between agents. All publicly accessible.
135,000+ instances exposed to the internet - the gateway binds to 0.0.0.0:18789 by default. SecurityScorecard tracked a jump from 40K to 135K in a single day. 63% classified as vulnerable.
Adversa AI warns: ~/.openclaw/ stores API keys, WhatsApp tokens, and Discord credentials in plaintext JSON and Markdown. Infostealers RedLine, Lumma, and Vidar are already building modules to harvest these files.
Gartner rated it an “unacceptable cybersecurity risk” - immediate ban recommended for enterprise.

And NanoClaw by Gavriel Cohen rewrote the core logic in ~500 lines of TypeScript. Five hundred. Auditable in a single afternoon. That says enough about the state of the original 300,000.

My problem isn’t with OpenClaw - as I said, my inner nerd is having the time of his life... in general, it’s fun. My problem is with the narrative in which a vibe-coded agent with three CVEs, 341 malware skills, and Gartner saying “ban this” gets presented as the future of programming - while an ecosystem with 30 years of production history is “boomer tech.”

Honest about Java’s problems - because we’re not fanboys

The rant edition format makes it easy to slip into Java is doing great, haters gonna hate mode. I’m not going there.

Java is unfortunately dropping in rankings - TIOBE February 2026: fourth place, ~8-9%. C# was named Language of the Year 2025. Paul Jansen openly asks whether “Java, with its verbose, boilerplate-heavy style and Oracle ownership, can continue to keep C# at bay.” Python is at 22%+. Rust - “most admired” for the ninth year running (82.2%). TypeScript has overtaken Java on GitHub. Stack Overflow 2025: only 15.8% of developers want to work in Java.

Of course, worth knowing only if you still care about StackOverflow opinion. You will be missed the old friend.

On top of that, the AI narrative favors Python and TypeScript - and not without reason. Vibe coding, agents, OpenClaw, Cursor, Claude Code - that’s TypeScript and Python. The feedback loop is shorter, the entry barrier lower, and LLMs generate better code in languages they were trained on. If you’re a junior in 2026, your first AI project will be in Python. One hundred percent. That’s a real problem for the JVM talent pipeline.

Unfortunately, Java is still perceived through the lens of version 8. It’s an ugly vicious cycle: the more people think of Java in terms of EJBs, getters, and AbstractSingletonProxyFactoryBean, the fewer newcomers bother to check what’s changed, which cements the image of an “old” language. We don’t help ourselves either — many of us live in a bubble and aren’t explaining loudly enough that Java 25 is a completely different language than Java 8.

These are real problems. Treating them as “hate” instead of signals is a mistake.

Now - the counterattack. Because the data tells a more interesting story than the Twitter narratives.

The JVM ecosystem hasn’t been sitting still. The GraalVM team, among others, decided to remind the world of a few facts. Rightly so.

Bruno Borges, Developer Advocate at GitHub (previously Microsoft, Oracle), created java.evolved - a site comparing old Java code with its modern equivalent. 86 comparisons, JDK 8 to JDK 25.

Take a look:

// Back then
public class Point {
    private final int x, y;
    public Point(int x, int y) { ... }
    public int getX() { return x; }
    public int getY() { return y; }
    // equals, hashCode, toString...
}

// Java 16+
public record Point(int x, int y) {}

// Back then
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

// Java 25
void main() {
    println("Hello, World!");
}

Virtual threads. Structured concurrency. Pattern matching in switch. Sealed classes. Gatherers in streams. This is not the same Java people picture when they say “enterprise bloat.”

So first action point from this piece: java.evolved - worth sending to anyone still citing Java circa 2015.

Now let’s look at an alternative perspective our community has been wielding like a shield - Thiago Mendes published an open-source benchmark of MCP servers in four languages - 3.9 million requests, three rounds, full code on GitHub. Each server in an identical Docker container (1 core, 1GB RAM), four identical test tools.

The headline number: Java (Spring Boot + Spring AI) achieved 0.835ms average latency vs Python (FastMCP) at 26.45ms. A 31x difference. Go right next to Java (0.855ms), Node.js in the middle (10.66ms).

But - let’s be honest - raw MCP server latency is rarely the bottleneck in practice. A typical flow looks like: LLM generates request (500–2000ms) → MCP routes to tool (those 0.8–26ms) → tool queries database/API (50–3000ms) → LLM processes response (500–2000ms). The bottleneck is the LLM - by a huge margin. Those 25ms difference between Java and Python drown in the seconds the model spends thinking. The end user won’t feel it. I think anyone who’s used any MCP in practice will confirm that.

Where this data actually matters is resource efficiency under load. And here the table says more than the latency numbers:

Java and Go handle 1600 req/s using ~30% CPU. They have headroom. Add more load - they’ll hold. Python and Node.js are already hitting the wall at 50 concurrent users. In practice that means: if you’re building an MCP gateway for one developer - Python is fine. If you’re building shared MCP infrastructure for an organization with hundreds of agents - the difference between 30% and 94% CPU utilization is the difference between “it works” and “we need three times as many Kubernetes pods.”

Disclaimer: Node.js with per-request instantiation (mitigation for CVE-2026-25536 - shared instance would be faster), Python with single-worker uvicorn (multi-worker would improve things), Java without JVM tuning.

So the Java is 31x faster than Python in AI claim - I wouldn’t push that too hard people. More accurately: Java and Go give you headroom that Python and Node.js don’t have, when MCP stops being a single developer’s toy and becomes infrastructure.

Which is exactly what I’d expect from it.

Moving on: the Azul 2026 State of Java Report (2000+ respondents) shows 62% using Java for AI functionality - up from 50% the year before. 31% say more than half of their Java applications contain AI.

Standard disclaimer from my side (of which there are many today) - this is a survey of people who already use Java, so there’s naturally a bias. But the trend is clear: Python dominates in prototyping and experimentation, Java in production.

The New Stack quotes Gil Tene, CTO of Azul:

People are not playing around making little demos; they’re making real applications with Java for AI.

The report summarizes it this way:

While Python might never relinquish its position as the top programming language for producing AI functionality, Java is becoming the default language for running the AI applications themselves.

Python prototypes. Java produces. Both are needed. But only one of them keeps banking systems on their feet at three in the morning.

One more thing that kind of blew my mind: 98% of respondents use AI tools to generate code (last year: 76%). 30% say more than half of new code is entirely AI-generated.

The “irrelevant in the AI era” ecosystem looks rather different in my head.

The about section of this newsletter has always featured a certain comic strip:

And as always, it’s still relevant.

“Java is dead” is its own literary genre by now. Paul Graham himself weighed in back in 2001 - we’ve had time to get used to it. Java survived applets, EJB, “XML everywhere,” the rise of Scala, Kotlin, Node.js, Go, Rust, and Python-as-the-one-true-language. It will survive “vibe coding killed enterprise Java” too.

But survival doesn’t mean no problems. Java has a real mindshare gap among new developers - and with every tweet like Steinberger’s, that gap widens. Few people have that kind of reach today.

Peter Steinberger is a great builder - this is definitely the Age of Builders. What’s more, OpenClaw is a fascinating project. But 300,000 lines of unaudited code with 135K open instances, Cisco catching malware in skills, Snyk finding 341 malicious packages, and Gartner saying “ban this” - that’s not proof that enterprise is dead. That’s proof that adoption ≠ quality. We are not living in the age of polished, Apple-like experience, I agree, but there is a need for both approaches.

And the narrative that “real programmers vibe, and the rest are enterprise boomers” is toxic. We should name it for what it is.

PS: Even if you’re up to date, still browse java.evolved yourself - 86 old-vs-modern comparisons are satisfying on an almost therapeutic level. Like organizing a sock drawer, but for programmers.

Discussion about this post

Ready for more?