[jason810496]

Why

Every task of a native Java Dag runs on the Java coordinator, so each one needs a queue that [sdk] queue_to_coordinator routes there. Airflow's Dag has no queue setting, so authors had to repeat the same queue on every task. The Go and TypeScript SDKs already take a Dag-level queue; this gives Java the same.

What changes

queue can be set once on the Dag, in both styles. Each task inherits it, unless the task sets its own queue.

// Annotation style.
@Airflow.Dag(id = "etl", schedule = "@daily", queue = "java")
public class Etl { ... }

// Interface style.
var dag = new DagDef("etl").config("queue", "java");
dag.task("extract", Extract.class);                           // runs on "java"
dag.task("heavy", Heavy.class).config("queue", "java_large"); // its own queue wins

• Same rules as Go and TypeScript: conditions, switches and TriggerDagRun tasks inherit the queue too, a task's own queue always wins, and the queue is never written on the serialized Dag itself.
• The native Java examples now set queue = "java", which the README's setup already routes to the Java coordinator.

---

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

• Yes, with help of Claude Code Opus 5.5 following the guidelines

[FrankYang0529]

Overall LGTM.

[uranusjr]

Should NativeBundleBuilder.java in the e2e suite also be updated to use this?

[jason810496]

Addressed in 0b8708d and 3f9633c.

On NativeBundleBuilder.java: yes, done in 3f9633c. All four e2e Dags (interface, annotation, target, dynamic) now set queue once on the Dag, and no task sets its own.

[jason810496]

Thanks for the review.

[github-actions]

Backport successfully created: v3-4-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-4-test