Skip to content

Refactor: Java wrapper call instrumentation into focused helpers#2075

Open
shreejaykurhade wants to merge 2 commits intocodeflash-ai:mainfrom
shreejaykurhade:refactor/create-wrapper-function
Open

Refactor: Java wrapper call instrumentation into focused helpers#2075
shreejaykurhade wants to merge 2 commits intocodeflash-ai:mainfrom
shreejaykurhade:refactor/create-wrapper-function

Conversation

@shreejaykurhade
Copy link
Copy Markdown

@shreejaykurhade shreejaykurhade commented Apr 20, 2026

This PR refactors wrap_target_calls_with_treesitter in codeflash/languages/java/instrumentation.py to reduce complexity without changing instrumentation behavior. Issue #526

The original function handled several responsibilities in one place:

  • filtering and ordering target calls
  • precomputing byte/character offsets for replacement
  • building timing/capture statements for instrumented calls
  • generating replacement code for expression-statement calls
  • generating prefix blocks for embedded calls
  • applying back-to-front source rewrites

That made the function harder to review and riskier to modify, especially in a part of the codebase with a lot of exact emitted-source expectations.

What Changed

The repeated preparation and code-generation logic is now split into focused private helpers:

  • _prepare_valid_calls
  • _build_call_statements
  • _build_expression_statement_replacement
  • _build_embedded_call_prefix_lines

wrap_target_calls_with_treesitter now acts as the orchestration layer for:

  • parsing the body with tree-sitter
  • collecting candidate calls
  • preparing valid call metadata
  • iterating through calls in reverse order
  • applying expression or embedded-call replacements

Why This Is Better

This improves maintainability by:

  • reducing the responsibility surface of the main wrapper function
  • separating metadata preparation from emitted-code construction
  • making the expression-statement and embedded-call paths easier to reason about in isolation
  • lowering the risk of future edits to one instrumentation path affecting another

This is intended to be a behavior-preserving refactor, not a logic change.

Behavior / Compatibility

No instrumentation behavior is intended to change.

In particular, this refactor preserves:

  • lambda and complex-expression filtering
  • call ordering and reverse-application semantics
  • void vs non-void handling
  • precise-timing vs non-precise-timing behavior
  • emitted marker / serialization / SQLite-write structure

Validation

uv run pytest -q tests/test_languages/test_java/test_instrumentation.py
uv run ruff check codeflash/languages/java/instrumentation.py

Results:

Both Passed
image
image

Risk

Low.

This change is a structural refactor in an area already covered by exact-string Java instrumentation tests, and the refactor preserves the original control flow rather than redesigning the instrumentation logic.

@shreejaykurhade
Copy link
Copy Markdown
Author

shreejaykurhade commented Apr 20, 2026

@Saga4 @KRRT7 please review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant