GenAI-Powered Automated Resource Leak Fixing in Java Codebases
uber · Tech · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: automated Java code repair
Uber needed to reduce manual, error-prone fixing of Java resource leaks across a large codebase after static-analysis tools such as SonarQube identified leaks but left the repair work to developers.
Constraints:
- resource leaks can cause performance degradation, application failures, and resource exhaustion
- manual fixes are time-consuming and prone to errors
- pre-GenAI template tools struggled to scale across Uber's massive codebase and new programming idioms
- blindly applying fixes can introduce use-after-close errors when resources outlive a function
- AI-generated code needed build, test, SonarQube, and developer-review validation before merge
Architecture
FixrLeak is a targeted GenAI code-repair framework for Java resource leaks. It starts from SonarQube-reported leaks, tracks each leak with a deterministic file/function hash, parses the target code with Tree-sitter, and uses AST-level analysis to skip unsafe cases where resources escape the function scope. For eligible intra-function leaks, it crafts a tailored prompt for GPT-4O, applies the suggested try-with-resources-style fix by replacing the leaky function, generates a pull request, validates builds/tests/SonarQube status, and leaves final acceptance to developer code review.
Diagram confidence: explicit (topology described by the source).
flowchart LR sonarqube-leak-scanner["SonarQube leak scanner"] --> leak-tracking["Leak tracking"] leak-tracking --> tree-sitter-parser["Tree-sitter parser"] tree-sitter-parser --> ast-safety-filter["AST safety filter"] ast-safety-filter --> prompt-builder["Prompt builder"] prompt-builder --> gpt-4o["GPT-4O"] gpt-4o --> patch-applier["Patch applier"] patch-applier --> validation-checks["Validation checks"] validation-checks --> pull-request-generator["Pull request generator"] pull-request-generator --> developer-review["Developer review"]
Components
| Component | Role | Interacts with |
|---|---|---|
SonarQube leak scanner |
Reports Java resource leaks and provides file names and line numbers for FixrLeak input gathering. | Leak tracking |
Leak tracking |
Uses deterministic file/function hashes to track leaks and fixes as code changes. | Tree-sitter parser |
Tree-sitter parser |
Parses Java code and extracts the relevant function for AST-level analysis. | AST safety filter |
AST safety filter |
Skips functions where resources are passed as parameters, returned, stored in fields, or otherwise outlive the function scope. | Prompt builder |
Prompt builder |
Creates a tailored prompt for eligible resource leaks. | GPT-4O |
GPT-4O |
Generates a suggested leak-free Java function, typically following try-with-resources best practice. | Patch applier |
Patch applier |
Replaces the original leaky function with the generated leak-free version. | Pull request generator, Validation checks |
Validation checks |
Builds the target binary, runs existing tests, and can recheck with SonarQube before PR submission. | Pull request generator |
Pull request generator |
Creates developer-reviewable pull requests for validated fixes. | Developer review |
Developer review |
Final human acceptance step for generated fixes. | — |
Data flow
SonarQube reports file names and line numbers for resource leaks. FixrLeak hashes the file/function identity, parses the relevant function with Tree-sitter, performs AST checks to ensure the resource is not passed, returned, or stored, sends a tailored prompt to GPT-4O for eligible leaks, applies the generated function replacement, runs build/test/SonarQube verification, and opens a pull request for developer review.
3 supporting quotes
Why this architecture
FixrLeak combines static analysis and GenAI because neither side is sufficient alone. SonarQube finds leaks but does not repair them; template tools struggled to scale; pure GenAI can be unsafe on complex cases. The AST safety filter narrows the task to high-confidence intra-function leaks, while build/test/SonarQube checks and code review protect the codebase from bad generated patches.
3 supporting quotes
Models used: FixrLeak · SonarQube · Tree-sitter · OpenAI ChatGPT-4O · GPT-4O · try-with-resources · Java · RLFixer · WALA · InferFix
Scale
- FixrLeak was deployed within Uber's extensive Java codebase.“Deployed within Uber’s extensive Java codebase, FixrLeak significantly reduces manual effort”article, stated
- Uber tested FixrLeak on 124 SonarQube-identified resource leaks.“we applied it to 124 resource leaks identified by SonarQube in Uber’s Java codebase.”article, stated
- Twelve deprecated-code cases were excluded.“After excluding 12 cases in deprecated code”article, stated
- AST-level analysis processed 112 leaks after deprecated-code exclusions.“FixrLeak’s AST-level analysis processed the remaining 112 leaks”article, stated
- Out of 102 eligible cases, FixrLeak automated fixes for 93 leaks.“Out of the 102 eligible cases, FixrLeak successfully automated fixes for 93 leaks.”article, stated
- InferFix is cited as having only 70% fix accuracy.“InferFix had its limitations, including only 70% fix accuracy and challenges with complex leaks requiring advanced code analysis.”article, stated
- FixrLeak continues to run periodically on Uber's Java codebase.“Fixrleak continues to run periodically on the Java codebase and will quickly generate fixes for resource leaks introduced in the future.”article, stated
Alternatives considered (roads not taken)
Manual developer fixes
Rejected because: Manual repair remained time-consuming and error-prone after static-analysis detection.
Template-based tools such as RLFixer
Rejected because: Templates and analysis frameworks worked for some leaks but did not scale well to Uber's massive codebase and required setup for new idioms.
Earlier GenAI repair systems such as InferFix
Rejected because: InferFix had 70% fix accuracy, struggled with complex leaks, and relied on proprietary models that were harder to adapt.
Blindly apply try-with-resources fixes everywhere
Rejected because: Closing a resource inside a function can break callers when the resource is returned, passed, or stored beyond the function's lifetime.
Patterns
tool-use-orchestration (code repair automation)
FixrLeak orchestrates static-analysis findings, Tree-sitter parsing, AST safety checks, LLM patch generation, validation commands, SonarQube rechecks, and PR creation into one automated repair workflow.
safety-policy-enforcement (code safety)
AST-level analysis acts as a safety gate, allowing GenAI repair only when the resource lifetime is confined to the allocating function.
structured-output-contract (code transformation)
The repair task is constrained to replacing the original leaky function with a new leak-free Java function that follows idiomatic try-with-resources practice.
human-in-the-loop-gate (developer workflow)
FixrLeak does not merge autonomously; it opens pull requests and relies on developers for final code review and acceptance.
eval-driven-development (verification)
Before submitting PRs, FixrLeak validates generated fixes by building the target binary, running existing tests, and optionally rechecking SonarQube leak resolution.
fallback-degradation (scope management)
FixrLeak deliberately leaves inter-procedural or caller-level resource-lifetime cases for future advanced analysis instead of forcing low-confidence fixes.
Tradeoffs
Repair scope
Chose well-scoped intra-function leaks over all resource leaks including inter-procedural cases.
Rationale: Constraining scope played to GenAI strengths and produced higher success rates while leaving harder cases for future analysis.
Repair technology
Chose GenAI plus AST-level analysis over template-only repair.
Rationale: GenAI avoids per-idiom template setup, while AST analysis preserves safety by filtering cases GenAI should not touch.
Merge policy
Chose PR-based human review after automated validation over fully autonomous patch merge.
Rationale: Automated validation makes fixes reviewable and low-effort, while developers retain final acceptance authority.
Detection source
Chose SonarQube reports as the initial leak source over GenAI-based leak detection in v1.
Rationale: The current workflow uses mature static-analysis detection and lists GenAI-based leak detection for future expansion, including Golang where tooling is missing.
Gotchas (what bit them)
Static-analysis detection does not solve repair effort.
Root cause: SonarQube can identify leaks, but developers still have to understand and fix each case manually.
Resolution: Use FixrLeak to gather leak context, generate a patch, validate it, and open a PR for review.
Naive resource-closing fixes can break callers.
Root cause: A resource may be returned, passed as a parameter, or stored in a field, meaning the caller expects it to remain open beyond the current function.
Resolution: Use Tree-sitter AST analysis to skip functions where the resource lifetime exceeds the allocating function.
Template-based repair struggles with new idioms.
Root cause: Pre-designed templates require manual setup for each new programming idiom and do not generalize cleanly across massive codebases.
Resolution: Use a template-free GenAI approach, but constrain it with static analysis and validation.
Generated code needs rigorous verification before developers trust it.
Root cause: An LLM-produced patch can compile incorrectly, break tests, or fail to remove the underlying static-analysis issue.
Resolution: Run target-binary builds, existing tests, optional SonarQube rechecks, and developer code review before merge.
The initial scope cannot fix resource leaks that span functions.
Root cause: Inter-procedural leaks require advanced caller-level analysis beyond the current function-local repair flow.
Resolution: Keep current automation focused on intra-function leaks and list inter-procedural fixes as a future capability.
Evaluation
Uber evaluated FixrLeak on SonarQube-detected Java leaks, excluded deprecated-code cases, filtered for AST-safe eligible repairs, measured successful automated fixes, and validates each generated fix through build, test, optional SonarQube recheck, and developer review.
Metrics: 124 SonarQube-identified leaks tested · 12 deprecated-code cases excluded · 112 leaks processed by AST-level analysis · 102 eligible cases · 93 successfully automated fixes · target binary build success · existing test pass · SonarQube leak resolved
3 supporting quotes
Outcomes
- FixrLeak automated fixes for 93 of 102 eligible resource leaks.
- It reduced manual repair effort by generating PRs developers could usually accept with one click.
- It continues to run periodically on Uber's Java codebase to fix newly introduced leaks.
- The team plans to expand to inter-procedural fixes, GenAI-based leak detection, Golang support, and advanced source-code analysis.
The case is production-scale inside Uber's Java codebase: 124 SonarQube-identified leaks were tested, 112 remained after deprecated-code exclusions, 102 were eligible, 93 were automated, and FixrLeak continues periodic runs on the Java codebase.