How Uber Uses GenAI to Fix Java Resource Leaks
Real-world programming workflows augmented by AI
There are bugs that scream when they break. Then there are bugs that whisper, quietly degrading performance, eating file handles, and lurking in the dark corners of your codebase.
Resource leaks in Java fall into that second category. You won't notice them until your thread pool chokes or your app fails to open a file. At scale, they're not just nuisances, they're systemic risks. And at Uber scale, they show up by the hundreds.
Fixing them sounds easy: just close your BufferedReader
. But in reality? The fix is often manual, error-prone, and thankless.
So Uber turned to generative AI to automate the whole thing, and caught the attention of developers worldwide who've been fighting the same battle.
🧩 The Problem: “You forgot to close it.”
In Java, failing to release resources like files or streams causes leaks. Sure, tools like SonarQube flag these, but fixing them is another story.
Historically, engineers relied on try/catch/finally
blocks, but forgetfulness (or just fatigue) meant many resources never got closed. Then came try-with-resources
, Java’s syntactic sugar that ensures safe cleanup.
But in a sprawling microservices codebase, retroactively migrating leaky code is expensive, and automating the fix is hard:
You can’t close resources that are returned from a method.
You can’t blindly refactor without introducing new bugs.
You have to ensure build integrity and test pass rates.
And that’s where Uber’s FixrLeak enters the picture.
⚙️ The System: AST-First, AI-Second
FixrLeak isn’t just an AI wrapper. It’s a pipeline. Here’s how it works.
Keep reading with a 7-day free trial
Subscribe to Byte-Sized Design to keep reading this post and get 7 days of free access to the full post archives.