DanielLeens commented on PR #11545:
URL: https://github.com/apache/seatunnel/pull/11545#issuecomment-5673874363
Going through each item at the current head (`81f12fffbd8`).
**F1 (idempotency) / F5 (fail-fast pre-check) — description update follows,
mechanics here for verification:**
Both `seatunnel-core/seatunnel-starter/src/main/bin/seatunnel.sh` and
`seatunnel-cluster.sh` do this identically, right before launching the JVM:
```bash
# SeaTunnel requires Java 11 or newer. Fail fast with an actionable message
instead of letting a
# JDK 8 launcher abort on the JDK 9+ module flags below with a cryptic
"Unrecognized option" error.
JAVA_MAJOR_VERSION=$(java -version 2>&1 | awk -F '[".]' '/version/ {print
($2 == "1") ? $3 : $2; exit}')
if [[ -n "$JAVA_MAJOR_VERSION" && "$JAVA_MAJOR_VERSION" -lt 11 ]]; then
echo "Error: SeaTunnel requires Java 11 or newer, but Java
${JAVA_MAJOR_VERSION} was detected. Point JAVA_HOME/PATH at a Java 11+ JDK." >&2
exit 1
fi
for module_flag in \
"--add-opens=java.base/java.lang=ALL-UNNAMED" \
... (6 flags total) \
"--add-exports=java.security.jgss/sun.security.krb5=ALL-UNNAMED"; do
case " ${JAVA_OPTS} " in
*" ${module_flag} "*) ;;
*) JAVA_OPTS="${JAVA_OPTS} ${module_flag}" ;;
esac
done
```
- **Minimum version / message (F5):** enforces Java 11, message is exactly
`Error: SeaTunnel requires Java 11 or newer, but Java ${JAVA_MAJOR_VERSION} was
detected. Point JAVA_HOME/PATH at a Java 11+ JDK.`
- **Idempotency key (F1):** each of the 6 flags is checked independently as
an exact, space-delimited substring of `JAVA_OPTS` (already built up from
`config/jvm_*_options` sourced earlier in the script) before being appended.
So: a user who hand-added a subset (say, just the `krb5` export) only gets the
other 5 appended — the one already present is left alone, not duplicated. This
is a literal string match, not a semantic one: a differently-formatted but
equivalent flag (e.g. a hand-added variant with different spacing) would not be
recognized as a duplicate and both would end up on the command line — harmless
for `--add-opens`/`--add-exports` since repeating them is a no-op, just not
deduplicated in that edge case.
I'll add this mechanics summary to the PR description under F1/F5 as
requested.
**F2 (silent Kerberos reflective-reload failure) — not silent, already
reported explicitly.** `KuduUtil.refreshJdkKerberosConfig()` /
`PaimonSecurityContext`'s equivalent catch `IllegalAccessException`
specifically (the exception JPMS throws when the export is missing) and log at
**ERROR**, distinct from other reflective failures caught at WARN:
```java
} catch (IllegalAccessException e) {
log.error(
"JVM module system denied the Kerberos configuration reload, so the
configured"
+ " krb5.conf will NOT take effect. Start the JVM with"
+ "
--add-exports=java.security.jgss/sun.security.krb5=ALL-UNNAMED"
+ " (shipped in config/jvm_*_options and appended by the launch"
+ " scripts since the Java 11 baseline).",
e);
}
```
For a user who starts the JVM without these launcher scripts
(embedded/custom launcher), this ERROR log is exactly the signal: if their
custom launcher doesn't pass the export, the very first Kerberos config reload
attempt logs this message naming the missing flag and where it's normally
supplied from.
**F3 (blanket `ALL-UNNAMED`, which flag serves which component).** Per-flag
attribution, now documented as comments directly above each flag in
`config/jvm_options`:
- `java.base/java.lang`, `java.base/java.nio`, `java.base/java.util`,
`sun.nio.ch` — Hazelcast internals (reflective access Hazelcast's own
client/server code needs).
- `java.base/java.net` — `URLClassLoader#addURL` reflection used by
`AbstractPluginDiscovery`, `ConfigValidationUtils`, and the Flink starter
plugin loaders to inject connector jars.
- `java.security.jgss/sun.security.krb5` — Kudu/Paimon/Debezium-CDC's
reflective krb5.conf reload (F2 above).
On why `ALL-UNNAMED` specifically (not a named target module): this project
has zero `module-info.java` files anywhere in the tree (checked via `git
ls-tree`), so every class — this project's own code and the shaded Hazelcast
dependency alike — loads into the JVM's unnamed module via the classpath.
`--add-opens`/`--add-exports ... =ALL-UNNAMED` is the only valid target for
opening/exporting to classpath code; there is no named module here to narrow it
to.
**F4/F7 (`upgrade_compatibility.yml` JDK version) — the underlying premise
doesn't match the current workflow.** I want to flag this clearly rather than
just answer the "if yes/if no" framing: the workflow does not run the old
release on JDK 17. The entire job — `actions/setup-java` with `java-version:
"8"`, then BOTH "Test upgrade compatibility tooling" (starts the old 2.3.13
release) AND "Build current dev distribution" (`mvn package -pl seatunnel-dist
-am`) — runs under a single JDK 8 toolchain, confirmed directly from that
workflow's own logs (`JAVA_HOME: .../Java_Temurin-Hotspot_jdk/8.0.504-1/x64`
persists through every step). This PR doesn't touch this workflow file or the
old release's bundled config at all, and adds no new
`--add-opens`/`--add-exports` content anywhere (see below), so there's no
interaction between this PR and that workflow to explain either way. The
workflow has been running green daily on `dev`, including today.
**F6/F8 (`JAVA_TOOL_OPTIONS` in `backend.yml`) — already resolved, restating
since this seems to have been missed.** Current `backend.yml` has zero
`JAVA_TOOL_OPTIONS` env entries; the only occurrences of that string are in the
explanatory comment describing why it's no longer set (replaced by the
`jdk9-plus-test-opens` Surefire/Failsafe profile plus the launcher-script
injection above). This was already confirmed in my `b75d9123be` follow-up
comment. Also, to be precise about scope for F1/F3 above: this PR makes
**zero** changes to the actual flag content of
`config/jvm_options`/`jvm_master_options`/`jvm_worker_options`/`jvm_client_options`
— only the per-flag comments and the launcher-script idempotent-append logic
are new. The `surefire.jvm.args` property in the `jdk9-plus-test-opens` profile
is a separate, test-only flag set that never reaches a packaged/launched
distribution.
Updating the PR description now to fold in the F1/F5 mechanics.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
