Using GenAI to Automatically Fix Java Resource Leaks

uber · Tech · 2024 · source Agentic: no · 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 effort fixing Java resource leaks detected by static analysis while avoiding unsafe automated changes that could introduce use-after-close or regression bugs.

Constraints:

• Resource leaks were detected by SonarQube but fixes were historically manual.
• Only intra-function leaks were safe enough for automated try-with-resources repair.
• Inter-procedural cases, returned resources, parameter resources, and class-field resources needed filtering.
• AI-generated patches had to build, pass tests, and undergo human review.
• The public case study does not detail cost, latency, or availability tradeoffs of GPT-4O.

Architecture

FixrLeak combines deterministic static analysis with GPT-4O code generation. SonarQube identifies Java resource leaks, Tree-sitter extracts the relevant function, AST checks filter out unsafe inter-procedural lifetimes, GPT-4O receives a scoped prompt for eligible intra-function leaks, the returned function replacement is applied, and automated build/test/SonarQube checks gate pull-request generation for human review.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  sonarqube-leak-detector["SonarQube leak detector"] --> leak-tracking-layer["Leak tracking layer"]
  leak-tracking-layer --> tree-sitter-parser["Tree-sitter parser"]
  sonarqube-leak-detector --> ast-eligibility-filter["AST eligibility filter"]
  tree-sitter-parser --> ast-eligibility-filter
  ast-eligibility-filter --> gpt-4o-repair-generator["GPT-4O repair generator"]
  gpt-4o-repair-generator --> patch-application-layer["Patch application layer"]
  patch-application-layer --> validation-pipeline["Validation pipeline"]
  validation-pipeline --> pull-request-generator["Pull request generator"]

Components

Data flow

SonarQube reports a resource leak with file and line metadata. FixrLeak tracks it with a deterministic hash, uses Tree-sitter to parse and extract the function, runs AST-level eligibility checks, prompts GPT-4O with the localized leak context, replaces the leaky function with the suggested fix, runs build/tests and optional SonarQube recheck, then opens a pull request for developer review.

Why this architecture

Uber constrained the LLM to a narrow, AST-vetted repair task instead of asking it to detect and reason about every resource-leak pattern. Deterministic tools find and bound the problem, while GPT-4O handles localized patch synthesis and the build/test/review pipeline catches regressions.

Models used: OpenAI GPT-4O · SonarQube · Tree-sitter

Scale

• SonarQube identified 124 Java resource leaks.
  “124 resource leaks were identified by SonarQube in the Java codebase”summary, stated
• Deprecated code accounted for 12 excluded cases.
  “12 cases in deprecated code were excluded”summary, stated
• AST analysis processed 112 leaks.
  “112 leaks were processed through AST-level analysis”summary, stated
• 102 cases were eligible for automated fixing.
  “102 cases were deemed eligible for automated fixing”summary, stated
• FixrLeak successfully fixed 93 leaks automatically.
  “93 leaks were successfully fixed automatically”summary, stated
• The eligible-case success rate was approximately 91%.
  “This represents approximately 91% success rate on eligible cases, and 75% of all non-deprecated leaks being fixed automatically.”summary, stated

Alternatives considered (roads not taken)

Use AI for leak detection as well as fixing

Rejected because: Uber used SonarQube for deterministic detection and left GenAI leak detection as future work.

Let the LLM fix all reported leaks

Rejected because: AST checks filtered cases where resource lifetime escaped the function scope.

Use template-only repair

Rejected because: FixrLeak used a template-free LLM approach while keeping deterministic filters and validation.

Patterns

tool-use-orchestration (code repair)

FixrLeak orchestrates SonarQube, Tree-sitter AST analysis, GPT-4O code generation, build/tests, and pull request creation.

safety-policy-enforcement (guardrails)

AST filters prevent GPT-4O from applying try-with-resources when resource lifetimes escape the function.

eval-driven-development (validation)

Generated fixes are gated by build, test, optional SonarQube recheck, and human code review before acceptance.

structured-output-contract (patching)

The LLM is prompted with a localized function and expected to return a replacement fix that can be extracted and validated.

Tradeoffs

Deterministic detection plus LLM repair

Chose Use SonarQube and AST analysis before GPT-4O generation over Use the LLM for both detection and repair.

Rationale: Trusted deterministic detection and eligibility checks reduced uncertainty before code generation.

Narrow resource-leak scope

Chose Automate intra-function resource leaks first over Attempt all Java resource-management bugs.

Rationale: Constrained scope produced higher accuracy and avoided unsafe lifetime assumptions.

Pull-request review remains in the loop

Chose Generate PRs after validation over Automatically merge generated fixes.

Rationale: Human review preserved code-quality control for subtle resource-management changes.

Gotchas (what bit them)

Blind try-with-resources fixes can introduce use-after-close bugs.

Root cause: Some resources are returned, passed as parameters, or stored in fields and therefore outlive the allocating function.

Resolution: AST-level analysis filters out escaping resource lifetimes before prompting GPT-4O.

High success depends on careful scoping.

Root cause: The hardest deprecated, inter-procedural, and failed eligible cases are excluded or remain unsolved.

Resolution: Uber started with well-scoped intra-function leaks and treats broader repair as future work.

AI-generated code still needs rigorous validation and review.

Root cause: LLM outputs can contain subtle errors even when they appear plausible.

Resolution: FixrLeak runs build/tests, optional static-analysis rechecks, and pull-request review.

Evaluation

Uber measured FixrLeak through SonarQube leak counts, AST eligibility filtering, successful automated fixes, build/test validation, optional SonarQube rechecks, and developer review.

Metrics: 124 leaks identified · 102 eligible cases · 93 successful automated fixes · 91% success on eligible cases · 75% of non-deprecated leaks fixed automatically

Outcomes

• FixrLeak automatically fixed 93 of 102 eligible Java resource leaks.
• The system fixed 75% of all non-deprecated leaks automatically.
• It runs periodically to generate fixes for future Java resource leaks.
• The approach reduces manual developer effort while retaining validation and review.

The evaluated deployment began with 124 SonarQube-detected Java resource leaks, filtered to 102 eligible cases, and fixed 93 automatically.