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]> 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]>> wrote:
>>
>>
>> > On 13 May 2026, at 20:42, Jarek Potiuk <[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]>
>> For additional commands, e-mail: [email protected]
>> <mailto:[email protected]>
>>
