feat: zero-config Java projects + smart ReplayHelper for end-to-end optimization

[misrasaurabh1]

Summary

Eliminates codeflash.toml for Java projects and fixes the complete trace → optimize pipeline to work end-to-end on real Java projects (validated on aerospike-client-java).

Zero-config Java support

• Auto-detect Java projects from pom.xml / build.gradle — no config file needed
• Read custom settings from pom.xml <properties> or gradle.properties (codeflash.* keys)
• Multi-module Maven scanning: parses each module's <sourceDirectory> / <testSourceDirectory>, picks module with most Java files as source root
• Deleted all codeflash.toml files

Smart ReplayHelper (behavior + performance parity)

• ReplayHelper.replay() now reads CODEFLASH_MODE env var and produces the same output as existing test instrumentation
• Behavior mode: captures return value via Kryo, writes to SQLite test_results table for correctness comparison
• Performance mode: runs inner loop for JIT warmup, prints timing markers matching the optimizer's expected format
• No mode: just invokes (trace-only or manual testing)

Bug fixes

• JFR parser: normalize / → . in class names (JVM internal format vs Java package format)
• Graceful timeout: send SIGTERM before SIGKILL so JFR can dump recording and shutdown hooks run
• TracingTransformer: remove isRecording() check that prevented instrumenting classes loaded during serialization (was causing 3 captures instead of 10,000+)
• Replay test generator: JUnit 4 support (org.junit.Test vs org.junit.jupiter.api.Test), detect from project build config
• Overloaded methods: global counter per method name to avoid duplicate replay test method names
• Instrumentation: fix _add_behavior_instrumentation for compact @Test lines (annotation + signature on same line)
• project_root: use build root directory (not sub-module) for multi-module Maven projects
• optimize subparser: add_help=False so -h in Java commands isn't intercepted as --help

Validated end-to-end on aerospike-client-java

• 10,500+ invocations traced across 282 methods
• 41 functions ranked by JFR CPU profiling data
• 55 replay test files generated (JUnit 4 compatible)
• Replay tests compile, run, and pass (129 tests for Crypto.computeDigest)
• Behavior baseline established with timing data (4.81ms over 119 loops)
• Candidates correctly verified and rejected when behavior doesn't match

Test plan

• 33 config detection tests (build tool, source/test root, Maven/Gradle properties, multi-module)
• 13 JFR parser tests (normalization, filtering, ranking, timeout, project_root)
• 10 replay test generation tests (JUnit 4/5, overloads, instrumentation)
• 8 tracer e2e tests (agent capture, replay generation, orchestration)
• 6 integration tests (full pipeline: discover → rank → compile)
• 2 replay test discovery tests
• Full optimizer pipeline on aerospike benchmark: trace → discover → rank → optimize → verify

🤖 Generated with Claude Code

[claude]

Claude finished @HeshamHM28's task in 4s —— View job

---

PR Review Summary

Prek Checks

✅ prek run --from-ref origin/main — clean, no issues.

Mypy reports 19 errors across models.py and discovery/functions_to_optimize.py, but these are all pre-existing (the PR only changes one line in models.py: runtime is not None). Not introduced by this PR.

Code Review

Binary file committed

codeflash/languages/java/resources/codeflash-runtime-1.0.0.jar is a binary file that changed in this PR (15.97 MB → 15.98 MB). This is expected since ReplayHelper.java and the tracer were updated, but binary files in git make diffs unreadable and repo size grows permanently. Consider whether this JAR should be built from source during CI (via mvn package) and excluded from source control via .gitignore, or if committing it is an intentional design choice for simplicity.

getCallingTestClassName() heuristic is fragile

ReplayHelper.java:getCallingTestClassName() walks the stack looking for a class name containing "ReplayTest" or "replay". Generated test classes are named ReplayTest_<classname> so this works for the happy path. However:

• The fallback (stack[3].getClassName()) could return a JUnit framework internal class (org.junit.runners.*) rather than the test class when JUnit uses reflection-based invocation
• For manually written tests that call helper.replay() from a class not matching these strings, the behavior mode will associate results with the wrong class name, causing comparison failures

A more robust approach would be to pass the test class name explicitly to replay() — but that would change the generated test format. At minimum, document this constraint.

Windows: SIGTERM not graceful

_run_java_with_graceful_timeout() in codeflash/languages/java/tracer.py:41 calls proc.send_signal(signal.SIGTERM). On Windows, this calls TerminateProcess() — the same as proc.kill(), so JFR can't dump its recording. The subsequent proc.kill() in the except handler is then a no-op on an already-dead process. Low severity (JFR/Java profiling is primarily Linux/macOS), but the code doesn't log a warning or handle the Windows case.

detect_java_project called twice at trace time

In codeflash/tracer.py:388-392, detect_java_project(project_root) is called to get test_framework. This is a redundant detection since the same config was already read during process_pyproject_config. If JavaProjectConfig.test_framework were propagated into the argparse Namespace during setup (similar to how tests_root and module_root are), this extra filesystem scan could be avoided. Minor, but worth a follow-up. Fix this →

replayBehavior invocation ID format

In ReplayHelper.java:replayBehavior(), invId = testMethodName + "_" + testIteration. The comment says testIteration goes at the END so the comparator's lastUnderscore stripping can make baseline/candidate keys match. However, testMethodName itself could already contain underscores (e.g., replay_computeDigest_42). If the comparator strips only the last underscore segment, this should be fine — but this is subtle coupling between the Java runtime and the Python comparator that is not documented anywhere. Adding a comment linking to the Python-side comparator logic would help future maintainers.

Duplicate Detection

No duplicates detected. The new functions (_run_java_with_graceful_timeout, generate_replay_tests JUnit4 support, getCallingTestClassName/MethodName) are unique to their modules.

Test Coverage

All 23 new tests pass (test_jfr_parser.py: 13 tests, test_replay_test_generation.py: 10 tests).

File	Coverage
jfr_parser.py	71%
replay_test.py	76%
instrumentation.py	61%
tracer.py (java)	33%
maven_strategy.py	9% (largely pre-existing)

tracer.py at 33% is low but most uncovered code is subprocess orchestration (_run_java_with_graceful_timeout, JavaTracer.trace()) that is inherently difficult to unit test. The graceful timeout logic has dedicated tests in TestGracefulTimeout. Acceptable for now.

---

Last updated: 2026-04-01T20:13Z

[mashraf-222]

Review & fix: pom.xml formatting preservation (3c63b60)

Reviewed the PR changes and identified one genuine issue in the config writer.

What was fixed

_write_maven_properties() and _remove_java_build_config() destroy pom.xml formatting — both used xml.etree.ElementTree which strips XML comments, mangles namespace declarations (xmlns → ns0: prefixes), and reformats all whitespace. Replaced with text-based regex manipulation that only touches codeflash.* property lines and preserves everything else. The new approach also detects existing indentation from sibling elements so inserted properties match the file's style.

Additionally:

• Extracted duplicated key_map dict to shared _MAVEN_KEY_MAP module constant
• Aligned _remove_java_build_config() to check pom.xml first, matching write priority
• Added 9 tests (7 for config_writer, 2 for detector confirming zero-config intent)

What was reviewed and left as-is

Confirmed the following are intentional design decisions, not bugs:

• has_existing_config() returning True for any Java build file — this is the zero-config mechanism that skips the first-run setup flow
• isRecording() guard removal in TracingTransformer — PR description explains this fixed captures going from 3 to 10,000+
• add_help=False on optimize subparser — prevents argparse from intercepting -h meant for Java command passthrough

Validation

• All 152 setup tests pass (including 9 new)
• All 8 tracer E2E tests pass
• Full Fibonacci E2E optimization: 279x speedup found, mark-as-success 200
• prek clean (ruff check + format)

[mashraf-222]

3 commits addressing the remaining open TODOs from the code review:

1. 5942ae9e — Monorepo config priority

parse_config_file() used to short-circuit on the first Java build file found, before the existing depth-comparison logic for package.json/pyproject.toml. In a monorepo with a parent pom.xml and a child package.json, Java would incorrectly win. Now all config sources are detected first and the closest one to CWD wins.

2. 12921447 — Tracer line numbers + dropped captures

• Line numbers: TracingClassVisitor hardcoded 0 because ASM's visitMethod() doesn't provide line info. Added a pre-scan pass in instrumentClass() that collects first line numbers via visitLineNumber() before the instrumentation pass.
• Dropped captures: Serialization timeouts silently dropped invocations with no tracking. Added AtomicInteger droppedCaptures counter and included it in flush metadata.

3. 970c9f86 — Package detection scope

Changed detect_packages_from_source() from 2 package components to 3, so com.aerospike.client.util → com.aerospike.client (was com.aerospike). Reduces instrumentation blast radius from entire organization to actual source package.

E2E validation

Fibonacci optimization: 258x speedup. Full pipeline (discovery → test gen → instrumentation → benchmarking → candidate evaluation) passed.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ mashraf-222
❌ Ubuntu

---

Ubuntu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}