feat(java): inject worker resources into handler methods

[pratyush618]

What

Adds @Resource — declarative worker-resource injection for @TaskHandler methods, resolved at compile time by the annotation processor (zero runtime reflection, GraalVM-clean).

• @Resource("name") (org.byteveda.taskito.annotation) — placed on handler parameters after the payload. Source-retention.
• TaskHandlerProcessor extension — the generated companion resolves each @Resource parameter by name from the worker's resource runtime (equivalent to Resources.use(name)) and passes it positionally, so a handler reads its DI dependencies as plain method arguments:

@TaskHandler("send_email")
void send(EmailPayload payload, @Resource("db") Database db) { ... }

Builds on the programmatic resource system (#340) — this is the declarative layer over it.

Test

AnnotationProcessorTest (+ ResourceGreeter fixture) — a handler with a @Resource-injected parameter after the payload resolves the named resource and runs end-to-end.

./gradlew build green (JDK 17 build leg + 21/25 test legs).

Summary by CodeRabbit

• New Features

  • Added support for task handlers that accept a payload plus additional named resource parameters.
  • Introduced a new parameter annotation for injecting named resources into handlers.

• Bug Fixes

  • Improved handler generation to correctly support methods with extra parameters and void returns.
  • Updated generated bindings to resolve resources at runtime when needed.

• Tests

  • Added coverage for handlers that use injected resources.

[pratyush618]

@CodeRabbit review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

\n\n[](https://app.coderabbit.ai/change-stack//pull/352?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)\n\n

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 52 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: afeeccb7-441f-4e3c-84f0-47413bbb3984

📥 Commits

Reviewing files that changed from the base of the PR and between 03b315d and 923db66.

📒 Files selected for processing (1)

• sdks/java/processor/src/main/java/org/byteveda/taskito/processor/TaskHandlerProcessor.java

📝 Walkthrough

\n\n

\n

📝 Walkthrough

\n\n## Walkthrough\n\nThis PR adds a @Resource parameter annotation for injecting named worker resources into @TaskHandler methods, updates TaskHandlerProcessor validation and code generation to support multi-parameter handlers via a new handlerExpr(...) helper resolving resources at runtime, and adds a corresponding test fixture and test.\n\n### Changes\n\nResource parameter injection\n\n|Layer / File(s)|Summary|\n|---|---|\n|@Resource annotation
sdks/java/src/main/java/org/byteveda/taskito/annotation/Resource.java|New source-retained, parameter-targeted annotation with a required value() element for the resource name.|\n|Processor validation
sdks/java/processor/.../TaskHandlerProcessor.java|Adds RESOURCE constant and VariableElement import; validate(...) now allows multiple parameters, requiring the first to be the payload and subsequent ones to carry a resolvable @Resource annotation.|\n|Handler expression generation
sdks/java/processor/.../TaskHandlerProcessor.java|Adds handlerExpr(...) and resourceName(...) to build method references or resource-resolving lambdas; wires this into bind(...) and handlers(...) generation, replacing prior void/non-void branching; conditionally imports Resources when any handler uses resource parameters.|\n|Test fixture and test
sdks/java/src/test/java/org/byteveda/taskito/ResourceGreeter.java, sdks/java/src/test/java/org/byteveda/taskito/AnnotationProcessorTest.java|Adds a ResourceGreeter handler using a @Resource(\"salutation\") parameter and a test registering the resource, enqueuing the task, running a worker, and asserting the resolved result.|\n\nEstimated code review effort: 3 (Moderate) | ~25 minutes\n\n### Sequence Diagram(s)\n\nmermaid\nsequenceDiagram\n participant Test as AnnotationProcessorTest\n participant Worker\n participant GeneratedBinder as ResourceGreeterTasks\n participant Resources\n participant Handler as ResourceGreeter\n\n Test->>Resources: register(\"salutation\", value)\n Test->>Worker: enqueue GREET task\n Worker->>GeneratedBinder: invoke bound handler(payload)\n GeneratedBinder->>Resources: use(\"salutation\")\n Resources-->>GeneratedBinder: resolved salutation\n GeneratedBinder->>Handler: greet(name, salutation)\n Handler-->>GeneratedBinder: result string\n GeneratedBinder-->>Worker: result\n Worker-->>Test: SUCCESS event with result\n\n\nPossibly related PRs\n\n- ByteVeda/taskito#340: Provides the Resources/ResourceRuntime infrastructure (Resources.use) that this PR's generated handlerExpr(...) code directly calls.\n\n

\n\n

\n\n

\n

🚥 Pre-merge checks | ✅ 5

\n\n

\n

✅ Passed checks (5 passed)

\n\n| Check name | Status | Explanation |\n| :------------------------: | :------- | :--------------------------------------------------------------------------------------------------------- |\n| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |\n| Title check | ✅ Passed | The title clearly matches the main change: adding worker resource injection to Java handler methods. |\n| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |\n| Linked Issues check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |\n| Out of Scope Changes check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |\n\n

\n\n

\n\n

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/java-resource-inject

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@sdks/java/processor/src/main/java/org/byteveda/taskito/processor/TaskHandlerProcessor.java`:
- Around line 61-71: In TaskHandlerProcessor’s parameter validation, the first
handler argument is currently accepted even if it is annotated with `@Resource`,
which lets the payload slot be misused. Update the validation around
method.getParameters() so the first parameter is explicitly required to be the
unannotated payload, and reject any `@Resource` annotation on params.get(0) before
checking the remaining parameters with resourceName(...). Keep the existing
error path in error(...) and the loop over params for later arguments, but add a
distinct check in TaskHandlerProcessor to enforce the API contract.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: fc1671c1-5327-4d85-8b1f-7e833d21c56c

📥 Commits

Reviewing files that changed from the base of the PR and between 1e489c4 and 03b315d.

📒 Files selected for processing (4)

• sdks/java/processor/src/main/java/org/byteveda/taskito/processor/TaskHandlerProcessor.java
• sdks/java/src/main/java/org/byteveda/taskito/annotation/Resource.java
• sdks/java/src/test/java/org/byteveda/taskito/AnnotationProcessorTest.java
• sdks/java/src/test/java/org/byteveda/taskito/ResourceGreeter.java