You can do the same if it’s in the task sdk, but 1. You need to use the same import path, but then you need to separately teach users to install a new package before moving it out. Not a very good user experience.
2. Or you use a different import path. You need to keep the old path working in the distribution for a long time *and* have users change their configs to fix the deprecation warning (and eventual breaking change). Unnecessary mental gymnastics on both sides. I really don’t understand the desire to have the Java coordinator inside the Task SDK distribution in the first go. The coordinator class must be public in the worker (at least the import path), and putting it in the SDK does not provide any more freedom to change it faster. It’s entirely the contrary since Task SDK releases require a lot more testing since the distribution contains many things, while providers (in a similar position to Airflow Core as coordinators to Task SDK) are released more frequently, and can have major version bumps on their own if needed. > On 14 May 2026, at 00:54, Jarek Potiuk <[email protected]> wrote: > > > You can create multiple instances of the same coordinator class. Pass > > appropriate arguments to suite your need. This is in the AIP. > > Yes. And you cand do exactly the same 1-1 if it's part of package and > embedded in "airflow-sdk" distribution? Or am I wrong? Why do you think it > would not be possible if it's part of task_sdk? > > On Wed, May 13, 2026 at 6:43 PM Tzu-ping Chung via dev > <[email protected] <mailto:[email protected]>> wrote: >> You can create multiple instances of the same coordinator class. Pass >> appropriate arguments to suite your need. This is in the AIP. >> >> [sdk] >> coordinators = { >> "jdk-11": { >> "classpath": "airflow.sdk.coordinators.java.JavaCoordinator", >> "kwargs": {"java_executable": >> "/usr/lib/jvm/java-11-openjdk/bin/java", "jars_root": ["/files/old/lib"]} >> }, >> "jdk-17": { >> "classpath": "airflow.sdk.coordinators.java.JavaCoordinator", >> "kwargs": {"java_executable": >> "/usr/lib/jvm/java-17-openjdk/bin/java", "jars_root": ["/files/new/lib"], >> "jvm_args": ["-Xmx1024m"]} >> } >> } >> >> The problem is, classpath points to a class, so whatever this string is >> needs to be kept compatible in future releases. >> >> >> >> > On 13 May 2026, at 23:59, Jarek Potiuk <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > > How do you make it changeable any time? User needs to be able to specify >> > > what coordinator to use in the config, and you can’t break that later. >> > We have only *jdk* coordinator now . So I will revert the question. How >> > are you going to configure two "jdk" `coordinators` when you have separate >> > distributions running "java"? Are you planning to install two >> > "coordinator-jdk" packages? This isn't possible in Python unless you build >> > almost the same package with jdk-11, jdk-19 built in? >> > My understanding is that you will have configuration options to choose >> > between "jdk-11" and "jdk-19." This "jdk" package of yours will simply >> > have a list of "jdks" linking to the Java interpreters. >> > >> > So, it doesn't matter if it's a single "coordinator-jdk" package or >> > everything in "airflow.sdk._coordinator."jdk" package or >> > "airflow.sdk._bridge.jdk" package in the task-sdk. Regardless, you cannot >> > install two "jdk" packages, whether they are separate distributions or if >> > the package is in "task-sdk" and you have to configure which of the "jdk" >> > bridges you want to use. >> > Yes. Sometime later, when we also have Go/TypeScript or other languages, >> > we might decide to centralize some APIs, create a "true" coordinator >> > package and separate distributions. And splitting into different packages >> > will be absolutely no problem then. Nothing will stop us from doing it. >> > >> > It will save a lot of time for all the "distribution" issue - including >> > releases, packagig, CI and everything connected - and it does not >> > absolutely block us from further split later. >> > >> > J. >> > >> > >> > >> > On Wed, May 13, 2026 at 3:47 PM Tzu-ping Chung via dev >> > <[email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> >> >> >> >> > On 13 May 2026, at 20:42, Jarek Potiuk <[email protected] >> >> > <mailto:[email protected]> <mailto:[email protected] >> >> > <mailto:[email protected]>>> wrote: >> >> > >> >> > Not really. I proposed an internal package that can be changed **any >> >> > time**. Users aren't supposed to use those items. We can clearly mark >> >> > them with "_" and also describe them thoroughly in the public API >> >> > documentation. And no. Initilaly providers were **not** in arflow at >> >> > all - you started from step 2. Step 1 is that they were added at some >> >> > point in time long before my time. Hooks and operators as "API" were >> >> > creaed quite early in the concept of Airflow - and the first >> >> > implementations were added then. Then, after common patterns emerged, >> >> > those hooks and operators were grouped into providers (they were not >> >> > initially) and only moved out after quite some time. As I see it - you >> >> > even admit yourself that things will look differently for different >> >> > languages, and maybe even we will not need bridges for some of them at >> >> > all. So why should we introduce new concept if we know currrently that >> >> > it applies only to "JDK"? I fail to see why we should proceed if we >> >> > already know the patterns are unlikely to be reusable in their current >> >> > form. >> >> >> >> How do you make it changeable any time? User needs to be able to specify >> >> what coordinator to use in the config, and you can’t break that later. >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> <mailto:[email protected]> >> >> <mailto:[email protected] >> >> <mailto:[email protected]>> >> >> For additional commands, e-mail: [email protected] >> >> <mailto:[email protected]> <mailto:[email protected] >> >> <mailto:[email protected]>> >> >>
