Fix Java SDK numeric XCom casting and remove unused XCom key field

[FrankYang0529]

1. Fix numeric XCom casting

Widen numeric XCom values through Number instead of casting the boxed value to the declared type:

• primitive targets: ((Number) client.getXCom(...)).intValue()
• boxed targets: Optional.ofNullable((Number) client.getXCom(...)).map(Number::intValue).orElse(null), so an absent XCom stays null rather than throwing.

2. Remove the unused key field from Builder.XCom

@Builder.XCom exposed a key field, but the annotation processor only reads task when generating the getXCom call, so key never affected the generated code.

---

Was generative AI tooling used to co-author this PR?

• Yes - Claude Code with Opus 4.8

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[jason810496]

Nice catch! LGTM overall.

[uranusjr]

Hmm, I wonder if we should do this since Python’s Taskflow API does not support using an argument to pull from a custom key; it only supports the return value. Maybe we should remove key from Builder.XCom instead?

[FrankYang0529]

Hmm, I wonder if we should do this since Python’s Taskflow API does not support using an argument to pull from a custom key; it only supports the return value. Maybe we should remove key from Builder.XCom instead?

Agreed, remove key from Builder.XCom. If user would like to pull a custom key, they still can do it via client.getXCom(key=..., taskId=...).

[uranusjr]

I just realized, we probably should mention in docs if you set up Builder.XCom to read into a primitive, but fail to actually push it, the cast would fail with a NullPointerException since there’s no way to represent a null in primitives. (By contrast, if you use e.g. Integer, you’d “safely” get null.)

We might want to add a case to emit a cleaner exception instead. This should be done in a separate PR.

[FrankYang0529]

We might want to add a case to emit a cleaner exception instead. This should be done in a separate PR.

I will do it in the next PR. Thank you.

[jason810496]

Nice! Thanks.