chore: bump codeflash-java-runtime to 1.0.1

[mashraf-222]

Summary

• Bumps codeflash-java-runtime version from 1.0.0 to 1.0.1 in pom.xml
• JAR 1.0.1 has been published to Maven Central

🤖 Generated with Claude Code

[claude]

Claude finished @mashraf-222's task in 2m 32s —— View job

---

PR Review Summary

• Triage PR scope — SMALL (version bump across 8 files, ~50 lines changed)
• Lint and type check — prek passed, no issues
• Resolve stale threads — none found
• Code review
• Duplicate detection

---

Prek Checks

All clean — ruff check and format passed.

Code Review

No binary JAR committed ✅
The old codeflash-runtime-1.0.0.jar is deleted and no new JAR is committed. Good — the JAR is fetched from Maven Central at runtime, as intended.

Logic change in add_codeflash_dependency — worth noting
The behavior changed from "only replace <scope>system</scope> dependencies" to "replace any existing codeflash-runtime dependency". This is intentional for version upgrade support (users running again after 1.0.0 was installed will get updated to 1.0.1), but it means the function now silently overwrites any pinned version a user may have set. This seems acceptable for a managed dependency, just flagging it as a behavioral change beyond a pure version bump.

Hardcoded JAR name in two places despite a centralized constant existing — minor
build_tools.py defines CODEFLASH_RUNTIME_VERSION = "1.0.1" and CODEFLASH_RUNTIME_JAR_NAME, but two files still hardcode the version:

• gradle_strategy.py:435: dest_jar = libs_dir / "codeflash-runtime-1.0.1.jar" — gradle_strategy.py already imports from build_tools, so this should use CODEFLASH_RUNTIME_JAR_NAME. Fix this →

• maven_strategy.py:574-575: The _M2_JAR class attribute hardcodes "1.0.1" and "codeflash-runtime-1.0.1.jar" — yet CODEFLASH_RUNTIME_VERSION and CODEFLASH_RUNTIME_JAR_NAME are already imported at the top of the same file. Should use those constants. Fix this →

build_tool_strategy.py:24 has _RUNTIME_JAR_NAME as a separate hardcoded constant — this is trickier since build_tools is only imported under TYPE_CHECKING there; worth a follow-up but not blocking.

Duplicate Detection

No duplicates detected. The version constant is intentionally split across build_tools.py (centralized) and two other files (hardcoded) — not a duplication of logic, but a consolidation opportunity noted above.

---

Last updated: 2026-04-01T23:17Z

[misrasaurabh1]

we are committing a jar file @mashraf-222