jedcunningham opened a new pull request, #76314: URL: https://github.com/apache/airflow/pull/76314
The JVM splits `-classpath` on `os.pathsep` (`:` on Linux) and has no quoting or escape for it. `JavaCoordinator` passed absolute JAR paths, so a Dag bundle whose path contains a colon, for example a version directory named after a timestamp such as `.../2026-11-02T15:52:20Z/`, was split apart. The JVM then failed with `ClassNotFoundException`, and the Dag failed to parse with `The Lang-SDK runtime exited with code 1 without a parse result`. `JavaCoordinator` now starts the JVM in the bundle root and lists the JARs relative to it, so the bundle's own path is never on the classpath. The classpath order is unchanged: the executable JAR comes first, then every other JAR in the bundle. `SubprocessCoordinator` gets a `_get_working_directory()` hook, used both for a Dag parse (`chdir` before `exec`) and for a task (`Popen(cwd=...)`). It returns `None` by default, so other coordinators keep their current behaviour. `java -jar` was considered because it accepts a colon in the path, but it ignores `-classpath`, so the bundle's dependency JARs would not load. #### Gotchas - The Java runtime now starts in the bundle root instead of the parent process's working directory. Java Dag or task code that opens files by relative path resolves them from there. - A colon in a file or directory name *inside* the bundle still cannot go on a classpath. That now fails with an error that names the JAR, instead of a `ClassNotFoundException`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
