feat: add Gradle build tool support for Java optimization

[HeshamHM28]

Summary

• Adds full Gradle executor support alongside existing Maven support, using init scripts to inject configuration without modifying project build files
• Implements Gradle compilation, classpath extraction, test execution, multi-module detection, runtime JAR installation, and JaCoCo coverage — all via --init-script
• Dispatches between Maven and Gradle at the entry points (run_behavioral_tests, run_benchmarking_tests, run_line_profile_tests) based on detect_build_tool()
• Reuses the existing build-tool-agnostic direct JVM execution path (_run_tests_direct) for the fast compile-once-run-many pattern

Files changed

File	Changes
build_tools.py	Init script management, classpath extraction, project info, runtime install, JaCoCo, multi-module detection
test_runner.py	Gradle compilation/execution, entry point dispatch, generalized multi-module root detection
config.py	Gradle compiler settings detection

Test plan

• All 788 existing Java tests pass (0 regressions)
• All 1499 language tests pass
• Verified on simple Gradle project: build tool detection, project info parsing, compilation, classpath extraction, test execution, direct JVM execution
• ruff check and ruff format pass
• End-to-end codeflash optimize test blocked by SSL certificate issue in environment (API unreachable)
• Test on multi-module Gradle project (rewrite repo requires Java 8 toolchain)

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[claude]

Claude finished @HeshamHM28's task in 6m 41s —— View job

---

PR Review Summary

• Triage: assess scope (substantive changes)
• Lint & type check
• Resolve stale threads (none found)
• Code review
• Duplicate detection
• Test coverage
• Merge optimization PRs (none open)

---

Prek Checks

✅ ruff check and ruff format — clean, no issues.

Mypy found 2 pre-existing errors in function_optimizer.py (not introduced by this PR):

• codeflash.languages.base does not export Language (used via indirect import)
• LanguageSupport has no attribute replace_function_definitions (called via protocol dispatch at line 438)

Neither is new — both are pre-existing mypy gaps not caused by this PR.

---

Code Review

Bug 1 (Medium): setup_coverage still uses raw brace counting for plugins {} block

gradle_strategy.py:781-793 — the plugins { } injection still walks the string character-by-character counting {/}. This is the same class of bug that add_codeflash_dependency had before being fixed with tree-sitter. Groovy plugins blocks can contain id "com.github.spotbugs" version "${spotbugsVersion}" where the } in ${spotbugsVersion} will prematurely terminate the scan. The fix to add_codeflash_dependency used tree-sitter; setup_coverage should do the same, or at minimum use a tree-sitter-backed approach for the plugins {} block too.

# gradle_strategy.py:784-793 — vulnerable to ${var} interpolation in plugin strings
for i in range(plugins_idx, len(content)):
    if content[i] == "{":
        brace_depth += 1
    elif content[i] == "}":
        brace_depth -= 1
        if brace_depth == 0:

Fix this →

Bug 2 (Medium): jacocoTestReport not qualified with module prefix in multi-module builds

gradle_strategy.py:604 — when test_module is set, the test task is correctly qualified as :{test_module}:test, but jacocoTestReport is appended as an unqualified task name. In multi-module Gradle projects, this causes Gradle to run jacocoTestReport for all subprojects (or fail if the root project doesn't have the jacoco plugin applied). It should be :{test_module}:jacocoTestReport.

# Current (line 604):
cmd.append("jacocoTestReport")

# Should be:
cmd.append(f":{test_module}:jacocoTestReport" if test_module else "jacocoTestReport")

Fix this →

Bug 3 (Low): _test_framework set twice in ensure_runtime_environment

support.py:548 — self._test_framework = config.test_framework is called in ensure_runtime_environment, but setup_test_config (line 410) does the same thing. Both paths call detect_java_project. This is harmless but redundant — if the config returns different results for different call sites (e.g., different project_root_path vs project_root), the second call would silently overwrite the first. Worth a comment or deduplication.

Observation: Module-level mutable caches in gradle_strategy.py and maven_strategy.py

Both files have module-level singletons (_classpath_cache, _multimodule_deps_installed, _skip_validation_init_path) that persist for the lifetime of the process. This is correct for production use (avoid re-running Gradle to get the classpath on every candidate). However, tests that mock or stub these paths must be careful to reset them between runs. The CompilationCache in test_runner.py uses a proper clear() method; consider doing the same for these dicts if test isolation ever becomes a problem.

Observation: _get_project_classpath cache pattern is unusual

function_optimizer.py:355-375 — the cache uses hasattr(self, "_cached_project_classpath") but the class body also has _cached_project_classpath: str | None as a class-level annotation. The hasattr check will always return True because of the class-level attribute declaration (even if the instance value hasn't been set yet). The instance-level assignment at line 373 (self._cached_project_classpath = classpath) shadows the class annotation, but the first hasattr check at line 363 will still see the class annotation. In practice this works (the annotation sets no value at class level) but it's subtly fragile — a better pattern is try/except AttributeError or using a sentinel like _UNSET = object().

---

Duplicate Detection

MEDIUM — add_codeflash_dependency defined in two files with different signatures

• maven_strategy.py:155 — add_codeflash_dependency(pom_path: Path) -> bool (Maven XML insertion)
• gradle_strategy.py:183 — add_codeflash_dependency(build_file: Path, runtime_jar_path: Path) -> bool (Gradle tree-sitter insertion)
• __init__.py:55 imports the Maven version only

These are intentionally different (different build file formats), so the name collision is the issue. Since both are exported/imported, it's easy to accidentally call the wrong one. Consider renaming the Gradle one to add_codeflash_gradle_dependency for clarity.

No other duplicates detected — _extract_modules_from_pom_content and _extract_modules_from_settings_gradle in test_runner.py are the single source of truth; other module detection code defers to them.

---

Test Coverage

File	Statements	Miss	Coverage
gradle_strategy.py	444	335	25%
maven_strategy.py	493	279	43%
build_tool_strategy.py	66	13	80%
test_runner.py	736	309	58%
function_optimizer.py	228	153	33%

gradle_strategy.py at 25% is expected for a new file that requires a real Gradle project to exercise the I/O paths. The GradleStrategy methods that need coverage: ensure_runtime, install_multi_module_deps, get_classpath, run_tests_via_build_tool, run_benchmarking_via_build_tool, setup_coverage. These are all integration-level paths that are hard to unit test without mocking subprocess, but unit tests for the pure-logic helpers (_parse_classpath_output, get_reports_dir, get_build_output_dir) and the tree-sitter dependency injection (_find_top_level_dependencies_block, add_codeflash_dependency) would be straightforward to add.

---

Overall: The refactor to a strategy pattern is clean and the Gradle support looks solid. The two medium bugs (brace counting in setup_coverage and unqualified jacocoTestReport in multi-module builds) should be fixed before merging, as the E2E validation on Netflix Eureka/Zuul has already confirmed both are triggered in real projects.

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 73% (0.73x) speedup for _extract_java_version_from_gradle in codeflash/languages/java/build_tools.py

⏱️ Runtime : 1.65 milliseconds → 954 microseconds (best of 243 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function _extract_java_version_from_gradle by 73% in PR #1774 (feat/gradle-executor-from-java) #1786

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 112% (1.12x) speedup for get_gradle_test_reports_dir in codeflash/languages/java/build_tools.py

⏱️ Runtime : 18.0 milliseconds → 8.47 milliseconds (best of 130 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function get_gradle_test_reports_dir by 112% in PR #1774 (feat/gradle-executor-from-java) #1787

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 84% (0.84x) speedup for get_gradle_test_classes_dir in codeflash/languages/java/build_tools.py

⏱️ Runtime : 25.9 milliseconds → 14.1 milliseconds (best of 124 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function get_gradle_test_classes_dir by 84% in PR #1774 (feat/gradle-executor-from-java) #1788

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

This PR is now faster! 🚀 @claude[bot] accepted my optimizations from:

• ⚡️ Speed up function get_gradle_test_reports_dir by 112% in PR #1774 (feat/gradle-executor-from-java) #1787

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 413% (4.13x) speedup for GradleStrategy.get_reports_dir in codeflash/languages/java/test_runner.py

⏱️ Runtime : 10.2 milliseconds → 1.98 milliseconds (best of 172 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up method GradleStrategy.get_reports_dir by 413% in PR #1774 (feat/gradle-executor-from-java) #1799

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 28% (0.28x) speedup for _get_strategy in codeflash/languages/java/test_runner.py

⏱️ Runtime : 2.58 milliseconds → 2.02 milliseconds (best of 150 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function _get_strategy by 28% in PR #1774 (feat/gradle-executor-from-java) #1800

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 52% (0.52x) speedup for MavenStrategy.get_build_output_dir in codeflash/languages/java/maven_strategy.py

⏱️ Runtime : 9.70 milliseconds → 6.40 milliseconds (best of 148 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up method MavenStrategy.get_build_output_dir by 52% in PR #1774 (feat/gradle-executor-from-java) #1801

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

This PR is now faster! 🚀 @HeshamHM28 accepted my optimizations from:

• ⚡️ Speed up method MavenStrategy.get_build_output_dir by 52% in PR #1774 (feat/gradle-executor-from-java) #1801

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 27% (0.27x) speedup for _validate_test_filter in codeflash/languages/java/test_runner.py

⏱️ Runtime : 3.14 milliseconds → 2.48 milliseconds (best of 98 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function _validate_test_filter by 27% in PR #1774 (feat/gradle-executor-from-java) #1803

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 13% (0.13x) speedup for _run_direct_or_fallback in codeflash/languages/java/test_runner.py

⏱️ Runtime : 3.92 milliseconds → 3.48 milliseconds (best of 156 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function _run_direct_or_fallback by 13% in PR #1774 (feat/gradle-executor-from-java) #1804

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

This PR is now faster! 🚀 @claude[bot] accepted my optimizations from:

• ⚡️ Speed up function _validate_test_filter by 27% in PR #1774 (feat/gradle-executor-from-java) #1803

[mashraf-222]

Blocker: Error Prone -Werror causes 100% compilation failure on Zuul (and any project using Error Prone)

Summary

Ran E2E --all optimization on Netflix Zuul (zuul-core, 820 functions) with the latest 5 commits on this branch. 82% of functions fail to compile because codeflash's instrumentation variables (_cf_*) trigger Error Prone [UnusedVariable] warnings, which become fatal compilation errors due to -Werror in Zuul's build.gradle.

The current _GRADLE_SKIP_VALIDATION_INIT_SCRIPT disables task-based static analysis plugins (checkstyle, spotbugs, pmd, rat, japicmp), but Error Prone is a compiler plugin — it runs inside javac via JavaCompile task options, not as a standalone Gradle task. The init script doesn't touch it.

What's happening

Zuul's build.gradle configures Error Prone as a compiler plugin with -Werror:

tasks.withType(JavaCompile).configureEach {
    dependencies {
        errorprone "com.uber.nullaway:nullaway:0.12.4"
        errorprone "com.google.errorprone:error_prone_core:2.45.0"
    }
    options.compilerArgs << "-Werror"
    options.errorprone { ... }
}

Codeflash instrumentation adds variables like _cf_fn, _cf_mod, _cf_cls, _cf_loop, _cf_test, _cf_outputFile, _cf_iter to the generated test classes. Some of these variables are declared but not read in all code paths, which triggers:

warning: [UnusedVariable] The local variable '_cf_test4' is never read.
        String _cf_test4 = "testServerInstanceAllocation_BypassesConstructor_InstanceNotNull";
               ^
    (see https://errorprone.info/bugpattern/UnusedVariable)

warning: [UnusedVariable] The local variable '_cf_outputFile4' is never read.
        String _cf_outputFile4 = System.getenv("CODEFLASH_OUTPUT_FILE");
               ^

warning: [UnusedVariable] The local variable '_cf_mod2' is never read.
        String _cf_mod2 = "ServerTest__perfinstrumented";
               ^

With -Werror, these warnings become fatal:

error: warnings found and -Werror specified

Scale of impact (from E2E session)

• Functions processed: 360 / 820
• Compilation failures: 297 (82.5%)
• Total [UnusedVariable] warnings: 10,072
• Total -Werror fatal errors: 349
• Distinct _cf_* variable names triggering errors: 80+ (e.g., _cf_fn1–_cf_fn14, _cf_mod1–_cf_mod14, _cf_cls1–_cf_cls14, _cf_loop*, _cf_test*, _cf_outputFile*, _cf_iter*)
• PRs created: 0

What the init script currently covers vs what's needed

Currently disabled (task-based plugins — works correctly):

checkstyleMain, checkstyleTest, spotbugsMain, spotbugsTest,
pmdMain, pmdTest, rat, japicmp

NOT disabled (compiler plugin — Error Prone):

• options.compilerArgs << "-Werror" on JavaCompile tasks
• Error Prone checks via options.errorprone { ... }

Suggested fix

Add Error Prone handling to the init script by stripping -Werror from compiler args:

gradle.projectsEvaluated {
    allprojects {
        tasks.withType(JavaCompile) {
            options.compilerArgs.removeAll { it == '-Werror' }
        }
    }
}

Alternatively (or additionally), suppress Error Prone's UnusedVariable check for test compilation:

gradle.projectsEvaluated {
    allprojects {
        tasks.withType(JavaCompile) {
            options.compilerArgs.removeAll { it == '-Werror' }
            if (options.hasProperty('errorprone')) {
                options.errorprone {
                    check('UnusedVariable', net.ltgt.gradle.errorprone.CheckSeverity.OFF)
                    check('EmptyCatch', net.ltgt.gradle.errorprone.CheckSeverity.OFF)
                }
            }
        }
    }
}

Context: What IS working well

For comparison, the same session on Eureka (JUnit 4 project, no Error Prone) produced:

• 109/411 functions processed, 50 compilations succeeded (46%)
• 7 speedups found (15.9%, 20.5%, 35.5%, 11.9%, 5.6%, 41.4%, 18.9%)
• 5 PRs created — the full Gradle pipeline works end-to-end when Error Prone is not present

The bug fixes in this branch (tree-sitter for build.gradle injection, JUnit version detection) are working correctly. Error Prone is the only remaining blocker for projects that use it.

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 21% (0.21x) speedup for get_optimized_code_for_module in codeflash/languages/code_replacer.py

⏱️ Runtime : 18.8 milliseconds → 15.5 milliseconds (best of 37 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function get_optimized_code_for_module by 21% in PR #1774 (feat/gradle-executor-from-java) #1849

If you approve, it will be merged into this PR (branch feat/gradle-executor-from-java).

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 22% (0.22x) speedup for _match_module_from_rel_path in codeflash/languages/java/test_runner.py

⏱️ Runtime : 3.77 milliseconds → 3.11 milliseconds (best of 47 runs)

A new Optimization Review has been created.

🔗 Review here