Java gets a Movie, Jakarta gets an AI Rewrite, and CUDA catches the Tornado(VM) - JVM Weekly vol. 184
A documentary about who actually built Java, an AI agent that reimplemented Jakarta EE from the spec, and TornadoVM conceding that portability has limits.
Before we jump in, a quick note: I was away last week 😁. I spent the week at my parents’ place and got completely distracted by the simple pleasures of countryside life. But now we’re back to our regular rhythm, and this week we have some genuinely interesting things to cover.
1. “The Java Story” premieres tomorrow
Okay, I have to confess something. My favorite film genre, right after modern horror, is the two-hour YouTube video essay. I absolutely love this format. It has become one of those rabbit holes I happily fell into, and creators like Super Eyepatch Wolf, Wendigoon, and many others constantly blow my mind with the quality of the documentaries they can produce. If you’ve ever thought you just don’t like documentaries, there’s a good chance you simply haven’t found one about a topic you genuinely care about. And thanks to YouTube, there’s an endless supply of them.
A memory from the last year one-week trip. My five-year-old daughter and her friend spent the evening watching “The Little Mermaid.” Meanwhile I was watching a Super Eyepatch Wolf video about a game I’d never even heard of… and I have a genuine feeling I had a better time.
Just check that classic:
Daaamn, I started to watch it again.
That’s why I was genuinely excited to see that some of the creators I know from their fantastic long-form documentaries have released a new feature-length video that’s already on my watch list. This time they’ve taken on the story of Java.
And the creators are the reason my expectations are set high: Cult.Repo formerly known as Honeypot - the people behind the React, Vue.js, Angular and Prometheus documentaries, who’ve made “document every major programming language ever created” their literal mission statement. If you’ve seen any of their Open Source Origin Story films, you know they treat this material like actual cinema (Garfield-level cinema!). Just two months ago they released a Spring documentary (with Rod Johnson explaining how a group of developers took back control from enterprise Java - watch it if you haven’t), so Java itself was the obvious next boss fight.
This Friday, July 17th at 7pm UTC, “Write Once. Run Forever: The Java Story” premieres on their YouTube channel - a full-length film about the language that, depending on who you ask, either quietly runs the world or died sometime around 2008. Somehow it manages to do both. Bonus: James Gosling and other cast members will be in the live chat during the premiere, which is not a sentence I get to type often.
The cast speaks for itself. From the Sun/Oracle side: James Gosling himself, Joshua Bloch (probably everybody here read Effective Java, didn’t you?), Brian Goetz, Mark Reinhold , Tim Lindholm (co-author of the JVM Specification), Kim Polese (Java’s first Product Manager and the person who gave “Oak” its final name), plus Georges Saab , Paul Sandoz, Carla Schroer, Sharat Chander, MBA , Heather VanCura and Duncan Davidson (Tomcat).
The community half is where it gets even more interesting: Rod Johnson (Spring), Gavin King (Hibernate), Andrey Breslav (Kotlin), Josh Long (Spring), Venkat Subramaniam (for being The Venkat, first Java speaker I felt in love platonically), Tagir Valeev (JetBrains), Ivar Grimstad (Jakarta EE), Paul Bakker (Netflix), Mark Little (IBM) and Lars Bergstrom, PhD (Google Android).
I’ve already had the chance to watch it (thank you Cult.Repo for the sneak peek, appreciate it!) and I can say it’s an exceptionally pleasant piece of filmmaking - it pulls you in far more than you’d expect from ninety-odd minutes about a programming language 😉. I sat down planning to skim it in the background and ended up watching the whole thing properly, which almost never happens to me with corporate-adjacent material.
So treat this as a recommendation with skin in the game: block out Friday evening, it’s worth it.
Just after you already watched SEW’s Garfield piece.
2. An AI agent reimplemented Jakarta EE... and the TCK let it pass. Crazy times
Every few months a project shows up that makes me re-read the announcement to be sure I understood it. Vidocq is one of those: a complete, open source implementation of the Jakarta EE Core Profile and MicroProfile. Fifteen self-contained modules, roughly 180,000 lines of Java, validated by 5,650 official TCK tests. Pure Java 25, JPMS-native, virtual-thread-first, zero external runtime dependencies. No ASM, no Byte Buddy, not even utility libraries.
A lot of good old human work!
Now the part that made me sit up. As the team explains in The Story of Vidocq, it was built as a spec-driven development experiment pushed to the extreme: an AI agent (Claude Code, to be precise) implementing the specifications, with the TCK as the merciless referee. I know how that sentence sounds. I also do this kind of AI-assisted engineering daily and co-wrote a book about it, so my bias is on the table - and that’s precisely why I want to push back on the lazy reading, which goes “AI can build frameworks now, panic accordingly.”
What actually matters here are oracles.
Left alone, an agent produces plenty of plausible-looking code that is quietly wrong - the single most reliable thing we know about them, and the reason OpenJDK just tightened its policy on AI-generated PRs. Vidocq is different because the problem came with an executable, non-negotiable definition of “correct” attached. The TCK doesn’t grade on “you are absolutely right!” - either 5,650 tests pass or they don’t; you can’t sweet-talk a compatibility kit. Give an agent a formal spec, a machine-checkable conformance suite and domain experts to steer it, and the feedback loop closes on its own. The agent grinds against a wall that tells it, every single time, when it’s wrong.
That framing also tells you where this generalizes - and where it doesn’t. Most software has no TCK. Most software has no formal spec at all, and “correct” is a matter of taste, shifting requirements and someone’s memory of a Slack thread. So Vidocq isn’t evidence that agents can build anything. It’s evidence that agents close the loop wherever a rigorous oracle already exists - and if one doesn’t exist in your codebase, building it is now arguably the highest-leverage engineering work there is. (Yes, this is roughly what my team at VirtusLab does for a living - I wrote about treating CI as the oracle in our Agent-Ready SDLC series - so calibrate my enthusiasm accordingly). Enterprise Java, having spent twenty years writing specifications and conformance kits nobody found glamorous, turns out to be unusually rich in that kind of terrain. The boring standardization work of the 2000s is what makes the 2026 experiment possible. There’s some poetic justice in that.
It helps that the humans involved aren’t anonymous prompt jockeys. Vidocq was initiated by Yann Blazart, Senior Tech Lead at SCIAM and co-creator of LangChain4j-CDI, with Antoine Sabot-Durand, Java Champion and former CDI, MicroProfile Fault Tolerance and Health spec lead. These two spent years writing the specs the agent was told to implement, and that’s most of the actual expertise. The agent didn’t discover CDI semantics; it was walked through them by people who’d notice the moment it got them wrong. The agent didn’t discover CDI semantics; it was walked through them by people who’d notice the moment it got them wrong. “Almost entirely built with AI” turns out to mean “with two spec veterans doing an enormous amount of supervision”, which is a very different sentence.
Time for some cold water, though, because this newsletter is not their press release. A TCK is a floor, not a ceiling. 5,650 passing tests prove conformance and say nothing about whether the thing is fast, memory-sane under load, secure against a motivated adversary, or well-behaved in concurrency corner cases no conformance kit fully covers. The project itself is refreshingly honest here - Vidocq is explicitly labeled alpha, with APIs and modules still expected to evolve. “Passes the TCK” and “I’d run it in production on Friday” are very different sentences - the gap between them is where twenty years of unglamorous hardening in the incumbents lives.
My biggest doubt is elsewhere anyway: green-field generation against a frozen spec is the easy case. The real test is maintenance. What happens when a CVE lands, when Jakarta EE 12 finally ships and moves the target, when someone files a bug that isn’t a TCK failure and a human has to reason about 180,000 lines nobody wrote by hand? Regeneration cuts both ways - superpower right up until you need a deep mental model of code no one on the team actually authored.
Personally, my prediction is that this is what software engineering becomes: code written by agents that can only be meaningfully maintained by other agents, while humans move up the stack to writing specs and tuning the machinery until it produces predictable results. Our job becomes writing increasingly rigorous contracts instead of software. I genuinely hope I’m wrong, because in that world most of the competitive advantage concentrates in the hands of the companies that own the models, while the rest of us run the AI factory... or build the factories. And I don’t say that lightly - my background is in automation and robotics, and I spent years trying to avoid ending up maintaining production lines for a living. Lately, software engineering has started to feel uncomfortably similar.
And I don’t say that lightly - my background is in automation and robotics, and I spent years trying to avoid ending up maintaining production lines for a living. Lately, software engineering has started to feel uncomfortably similar.
Same goes for the “zero dependencies” boast. Zero inherited CVEs also means zero inherited fixes - reimplement ASM and friends from scratch and you now own every subtle bug the ecosystem found and patched over two decades. Sometimes sovereignty and plain old Not-Invented-Here are hard to tell apart from the outside. I lean optimistic on Vidocq, but ask me again in a year, after it has survived contact with a security advisory and a moving spec. Agents are very good at writing things from scratch. What they’re much worse at is learning to stitch existing libraries together in a sensible way. They have a strong tendency toward an agentic version of Not-Invented-Here.
What I find genuinely interesting is the “100% sovereign European stack” framing, which I want to take more seriously than a marketing line usually deserves, because it plugs Vidocq into a discussion running well beyond our corner of the industry. “Digital sovereignty” is one of those phrases you now hear on every European front at once: dependence on US hyperscalers, critical materials and PCB supply chains, and - loudest of all - energy. My VirtusLab colleague 🌳 Pawel (Paul) Dolega (our CTO) has been making the energy version of this argument for a while: Europe’s real constraint over the next decade isn’t ideas but the physical and industrial base to run them on.
I bring it up because Vidocq is the same argument in miniature, one abstraction layer up: sovereignty isn’t a slogan, it’s a property of your dependency graph. And here it’s not just framing - the project is hosted on Codeberg, a European community forge, and released under a triple license that includes the EUPL, the European Union’s own public license. Zero external runtime deps means zero inherited CVEs and zero code you didn’t choose to run. If Vidocq has a market beyond the demo, it’s exactly here - regulated, public-sector, sovereignty-mandated buyers who care whether their runtime is European and auditable to the last line. The catch: that buyer is also the most conservative one in the industry. The organisation that mandates a sovereign stack usually also wants a decade of references, formal certification and a vendor to call at 3am. “Two people and an AI agent, hosted on Codeberg” is a hard sell to a procurement department that still asks for ISO paperwork. The demand thesis and the trust problem point in opposite directions, and that’s the whole difficulty in one sentence.
Here we come to the uncomfortable question underneath: not “does it work” but “does anyone want it.” If the Java world is not short of anything, it’s Jakarta EE and MicroProfile runtimes. WildFly, Open Liberty, Payara, GlassFish, TomEE, Helidon, Quarkus - a mature, arguably over-served, consolidating market, not a greenfield with a Vidocq-shaped gap. Momentum in enterprise Java has been draining away from full-profile app servers for years, toward Spring Boot and the Quarkus/Micronaut camp, and MicroProfile itself, whatever its technical merits, sits in a fairly niche corner of that shrinking space. A brand-new Core Profile implementation in 2026 is not a question many teams are asking. Nobody rips out a decade-proven Open Liberty deployment for a marginally smaller footprint from an unproven newcomer - not without a compliance gun to their head.
However, not everything needs a clear commercial market, and one idea here deserves its own paragraph, because it’s the genuinely new mechanism the AI angle unlocks: if you can regenerate an implementation from its spec, you don’t have to inherit one. The dependency graph stops being a fixed cost and becomes something you can choose to synthesize stops being a fixed cost and becomes something you can choose to synthesize - the same move from “depend on someone else’s infrastructure” to “own your own” the whole sovereignty debate keeps circling, energy included. It also loops back to the oracle argument: you can only safely regenerate what you can rigorously verify, and a TCK is what makes “regenerate the whole Core Profile” a sane sentence rather than a reckless one.
There’s honest craft underneath, too. All metadata is produced at compile time via the Class-File API (JEP 484) and annotation processing - no reflection, no dynamic proxies, no startup scanning - so the stack is jlink, jpackage, GraalVM and Leyden-ready out of the box. Sources live on Codeberg rather than GitHub, which in 2026 reads less like a quirk and more like part of the thesis.
Production runtime or brilliant proof of concept - either way, Vidocq just moved the goalposts of the “can agents build real systems” debate, and did it off to the side of the platform, by two spec veterans and a machine. The same pattern the documentary keeps returning to - somebody off to the side of the platform deciding they can build it better themselves, playing out live, this time with an agent on the team. Hold the “portability” thought for the next one.
Production runtime or brilliant proof of concept - either way, Vidocq just moved the goalposts of the “can agents build real systems” debate, and did it off to the side of the platform, by two spec veterans and a machine. The documentary’s pattern, playing out live.
And I still remember the arguments over whether Anthropic’s claim of having built a working C compiler was genuinely significant or completely meaningless. Fittingly, that experiment leaned on GCC’s torture tests as its verifier - and when the agents got stuck on the Linux kernel, Carlini used GCC itself as an oracle, compiling most files with it and only a random subset with Claude’s compiler to localize the bugs. Same trick, different compatibility kit. Wherever agents ship something real, you’ll find a merciless referee standing right behind them. Today it’s clear the conversation has moved much, much further.
Hold the “portability” thought for the next one.
3. TornadoVM 5.0.0 admits portability needs an escape hatch
The other “around the platform” story this fortnight is about GPUs, and it lands on the question every AI-adjacent Java developer keeps asking: do I have to leave the JVM to get real throughput? TornadoVM has appeared here often enough that you know the pitch - GPU acceleration without leaving Java - and version 5.0.0, announced by the TornadoVM team on July 10th, is where the answer starts being a credible “no.”
Java methods are now JIT-compiled straight to real CUDA C through NVIDIA’s own NVRTC → cubin pipeline, instead of a lowest-common-denominator kernel that merely happens to run on CUDA. That direct path unlocks things previously out of reach: CUDA Graphs (withCUDAGraph() records a task graph once and replays it via cuGraphLaunch), CUDA Streams for intra-plan concurrency, and Tensor Core MMA primitives in KernelContext that compile down to actual mma.sync.aligned PTX - the very instruction hand-written CUDA C++ ends up at.
What I find most telling is philosophical rather than technical. TornadoVM’s original identity was portability: write your kernel once, run it on any accelerator, don’t marry a vendor. Going native-CUDA is, if we’re honest, a concession - an admission that you can’t be taken seriously for LLM inference in 2026 on portable, vendor-neutral kernels alone. Sometimes you just need cuBLAS. What I like is how they conceded. The new Hybrid API (TaskGraph.libraryTask()) doesn’t throw portability out` - it lets you drop a native cuBLAS, cuFFT or cuDNN call into a task graph right next to your JIT-compiled Java tasks, on the same managed device buffers and stream pool, no host copies in between.
Portable by default, vendor-tuned native code per task, exactly where it pays off. The fine print: that escape hatch is one-way. The moment a libraryTask() calls cuBLAS, that graph runs only where cuBLAS exists - which is the same bargain the JVM’s native intrinsics always were, just with a greener logo.
Sound familiar? It’s the JVM’s oldest trick, re-enacted one layer down: portable bytecode everywhere, intrinsics and native code where performance demands it.
TornadoVM recapitulated Java’s entire portability-with-escape-hatches philosophy at the GPU boundary, which is a very on-brand way for a JVM project to solve this problem. The benchmark makes the payoff concrete. Memory-bound matrix-vector multiply on an RTX 4090: sequential Java 1×, the annotated-loop API 2.6×, TornadoVM’s own JIT kernel 52×, one line of cuBLAS via the Hybrid API 74×. Same TaskGraph, same buffers. Java’s job is to be a good enough host that territory everyone assumes belongs elsewhere turns out to be defensible from inside the JVM after all. That’s the portability thought, fully paid off: thirty years later, “write once, run forever” survives not by refusing escape hatches, but by knowing exactly where to put them.
Look at what every example is shaped like, too: dense layers, attention math, cuDNN softmax. TornadoVM is openly staking a claim on LLM inference, the workload conventional wisdom hands to Python and C++. It rhymes with Vidocq staking a claim on enterprise runtimes. Java’s job is to be a good enough host that territory everyone assumes belongs elsewhere turns out to be defensible from inside the JVM after all.
sdk install tornadovm 5.0.0-jdk21-cuda if you want to reproduce the numbers.
PS: Nolan’s “Odyssey” this weekend, I hope you are prepared. All week I’ve been pumping myself up with “EPIC: The Musical” - history of that little thing is articleworthy itself 😊.
PS2: And since this edition turned out unexpectedly cinematic, one more confession: “Vidocq” (2001) - the gloriously unhinged Depardieu one, shot entirely on digital cameras back when nobody was sure that was a good idea - is one of my all-time guilty pleasures, close to the Revenge of the Siths.
The runtime is officially named after the criminal-turned-detective who founded the Sûreté (BTW: The Century of the Detective book tells that story) which for a project whose whole thesis is “you can’t con the TCK” is almost too fitting.
But in my head-canon, it’s named after the movie. Did you catch the reference in today’s cover graphic 😉?
Good read as always, but you repeated yourself several times