neoLsH opened a new pull request, #12839:
URL: https://github.com/apache/gravitino/pull/12839
## What does this PR do?
Fixes #10350.
`bin/common.sh.template` gates the JVM version at **17 or newer**:
```bash
if [[ "$JVM_VERSION" -lt 17 ]]; then
echo "Error: Gravitino requires Java 17 or newer, but found Java
${JVM_VERSION}."
exit 1
fi
```
So starting Gravitino on JDK 21 is an accepted configuration. Every launch
template, however, guards its `--add-opens` block with an **equality** test:
```bash
if [[ "$JVM_VERSION" -eq 17 ]]; then
JAVA_OPTS+=" --add-opens java.base/java.nio=ALL-UNNAMED"
... # 22 flags in total
fi
```
On JDK 21 the version gate passes, the server starts, and all 22
module-access
flags are silently dropped. Arrow's `MemoryUtil` then cannot reach
`java.nio.Buffer.address` and fails exactly as reported in #10350:
```
java.lang.RuntimeException: Failed to initialize MemoryUtil. You must start
Java
with `--add-opens=java.base/java.nio=ALL-UNNAMED`
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
field
long java.nio.Buffer.address accessible: module java.base does not "opens
java.nio" to unnamed module
```
The two checks disagree about what "supported" means: the gate says `>= 17`,
the
guard says `== 17`. This aligns the guard with the gate.
## Why `-ge 17` rather than tightening the gate to `-eq 17`
Two reasons:
1. The gate's own error message ("requires Java 17 **or newer**") states the
intent, and `check_java_version` deliberately parses multi-digit versions
(including the `1.x` legacy form) so it can compare them numerically.
2. #7976 asks for JDK 21 to work, so the project's direction is forward.
Rejecting newer JVMs at startup would be a behaviour regression for anyone
currently running them.
The flags themselves stay safe on newer JVMs: the block already sets
`-XX:+IgnoreUnrecognizedVMOptions` first, so any option a future JVM drops is
tolerated rather than fatal.
If maintainers would rather restrict the runtime to exactly JDK 17, the
consistent change is in `check_java_version` (reject `> 17` with a clear
message) instead of leaving the server to start in a state where Arrow cannot
initialise. Happy to switch to that if preferred.
## Changes
`-eq 17` -> `-ge 17` in all four launch templates:
| File | Line |
|---|---|
| `bin/gravitino.sh.template` | 156 |
| `bin/gravitino-lance-rest-server.sh.template` | 155 |
| `bin/gravitino-iceberg-rest-server.sh.template` | 155 |
| `bin/gravitino-optimizer.sh.template` | 53 |
4 files changed, 4 insertions(+), 4 deletions(-). No other occurrence of
`-eq 17` exists in the repository, and there is no pre-existing `-ge 17`
variant to reconcile with.
## How was this tested
**Root cause reproduced.** The version parser from `check_java_version()` was
extracted verbatim and fed the `-version` banner of several JVMs, then both
the
gate and the guard were evaluated against the parsed value:
| `java -version` banner | `JVM_VERSION` | gate `-lt 17` | guard `-eq 17`
(before) |
|---|---|---|---|
| `openjdk version "17.0.9" 2023-10-17` | 17 | PASS | 22 flags applied |
| `openjdk version "21.0.2" 2024-01-16` | 21 | PASS | **0 flags applied** |
| `openjdk version "25" 2025-09-16` | 25 | PASS | **0 flags applied** |
| `java version "1.8.0_401"` | 8 | blocked | n/a |
JDK 21 and 25 clear the gate but lose every flag, which is the reported
failure.
**Fix verified.** After the change the guarded block was sourced with
`JVM_VERSION` set to 17, 21 and 25; all three now yield 22 `--add-opens`
flags
including `java.base/java.nio=ALL-UNNAMED`. JDK 17 behaviour is unchanged.
**Syntax checked.** `bash -n` passes on all four modified templates.
## Scope
Runtime launch scripts only. This does not overlap with #11124, which
addresses
*compile-time* JDK 21 support in `build.gradle.kts` and
`gradle/libs.versions.toml`
and touches no file under `bin/`. Both are needed for JDK 21 to work end to
end,
and they are independent.
--
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]
