Summary

Adds a new module dd-java-agent/instrumentation/spark/sparkjava-2.3-gen containing an alternative SparkJava 2.3 instrumentation generated end-to-end by the APM instrumentation toolkit's new_integration workflow.

The new module is placed alongside the existing sparkjava-2.3 module (not replacing it) so reviewers can compare the toolkit-generated implementation against the canonical one side by side. This is a research artifact — the goal is to evaluate how well the toolkit can produce a Java instrumentation that passes CI without human intervention.

What's in this PR

No changes to any production files or other modules.

How the toolkit produced this

One agent-driven workflow run from a blind baseline (the existing sparkjava-2.3 module was hidden from the agent). The workflow ran for ~2.5 hours, cost ~$74, and went through 10 reviewer iterations before the workflow exited.

Key choices the agent made:

• Target: spark.route.Routes.find() — same instrumented type as the existing sparkjava-2.3 module (which is named RoutesInstrumentation)
• Approach: enriches the existing Jetty server span with http.route rather than creating a new span. Matches existing pattern — Jetty is always the embedded server under SparkJava, so a server span always exists
• Muzzle directives: open-ended [2.3,) with assertInverse = true
• Tests: Spock specs extending HttpServerTest for full server-span validation

Verification

Local CI-equivalent verification on the new module:

./gradlew :dd-java-agent:instrumentation:spark:sparkjava-2.3-gen:check \
          :dd-java-agent:instrumentation:spark:sparkjava-2.3-gen:muzzle \
          :dd-java-agent:instrumentation:spark:sparkjava-2.3-gen:latestDepTest
BUILD SUCCESSFUL in 46s

Multi-JVM matrix (JVM 8/17/21/25) not run locally; the standard CI pipeline will exercise that.

Reviewer notes

The toolkit's internal reviewer step did NOT approve this module — it ran 10 iterations and exited with todos_remaining=7. The recurring spec-compliance complaint was that the agent should have instrumented spark.http.matching.MatcherFilter.doFilter (and created its own server span) instead of using Routes.find() + Jetty span enrichment.

I cross-referenced this against the existing sparkjava-2.3 module on master:

• File: dd-java-agent/instrumentation/spark/sparkjava-2.3/src/main/java/datadog/trace/instrumentation/sparkjava/RoutesInstrumentation.java
• instrumentedType() returns "spark.route.Routes"
• Does NOT call startSpan — relies on Jetty's existing instrumentation

So the agent's choice matches the existing canonical pattern. The reviewer's spec-compliance critique appears to be applying generic HTTP-server guidance ("each framework should own its server span") that doesn't fit this library's established convention.

Reviewers familiar with SparkJava should evaluate whether the existing pattern is itself correct. If it is, this PR is functionally equivalent to the existing module and can be considered a successful toolkit reproduction. If the existing module should be refactored to create its own span, this PR has the same issue.

Test plan

• CI builds the new module
• CI runs :sparkjava-2.3-gen:test and :sparkjava-2.3-gen:forkedTest
• CI runs :sparkjava-2.3-gen:muzzle
• CI runs :sparkjava-2.3-gen:latestDepTest
• Multi-JVM matrix (JVM 8/17/21/25) passes
• No conflict with existing sparkjava-2.3 module (the two should coexist; we may want to disable one or pick one before merging)

Provenance

Research artifacts (agent transcript, hypothesis file, all skill changes the toolkit applied) are preserved in DataDog/apm-instrumentation-toolkit branch eval/java:

• docs/eval-research/runs/sparkjava/attempt3-final/ — lean snapshot
• docs/eval-research/hypotheses/sparkjava.md — hypothesis file documenting the research finding

This PR is a draft for review only — not intended for merge as-is. The duplicate module would need to be reconciled (likely by replacing the existing sparkjava-2.3 with this one, or by withdrawing) before merging.

🤖 Generated with Claude Code