feat: Use Java 25 in Besu docker image

[usmansaleem]

PR description

feat: Use Java 25 in Besu docker image.

Due to JEP-493, we can't use jlink to create a custom Temurin JRE, hence we use direct copy from Temurin image which results in "ALL-MODULE" JRE.

Architect specific JRE will be picked by the Temurin image. For example, on Mac (aarch64):

./gradlew distDocker
docker run --rm hyperledger/besu:25.10-develop-11ef567 --version
besu/v25.10-develop-11ef567/linux-aarch_64/openjdk-java-25

Fixed testDocker task. Download dgoss/goss from build script instead of CI. This allows running ./gradlew testDocker in dev environment as well.

Added Java 25 tuneup options from #9346

TODO: Verify Windows batch script.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests
• hive tests: Engine or other RPCs modified?

[Copilot]

Pull Request Overview

This PR upgrades Besu's Docker images to use Java 25 (Eclipse Temurin JRE) instead of the previously embedded OpenJDK 21. Due to JEP-493 restrictions preventing jlink usage, the JRE is now copied directly from the Temurin base image. The PR also refactors Docker testing infrastructure by moving goss/dgoss downloads from CI workflows into the Gradle build script, enabling local test execution.

Key Changes:

• Upgraded Docker images from OpenJDK 21 to Eclipse Temurin JRE 25
• Added Java version detection and conditional JVM options for Java 25+ in startup scripts
• Moved goss/dgoss download logic from GitHub Actions workflows to Gradle build script

Reviewed Changes

Copilot reviewed 13 out of 15 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
docker/Dockerfile	Updated to multi-stage build copying Temurin 25 JRE; removed OpenJDK 21 apt installation
ethereum/evmtool/src/main/docker/Dockerfile	Similar updates for evmtool image using Temurin 25 JRE
app/src/main/scripts/unixStartScript.txt	Added Java version detection to conditionally apply Java 25 JVM options
app/src/main/scripts/windowsStartScript.txt	Added Java version detection for Windows batch script
docker/test.sh	Refactored test execution with architecture detection and improved error handling
docker/tests/dgoss	Removed dgoss script (now downloaded by Gradle)
docker/tests/00/goss.yaml	Removed static Dockerfile tests (moved to runtime validation)
docker/tests/01/goss.yaml	Added runtime environment variable validation commands
docker/tests/README.md	Added documentation for running Docker tests
.github/workflows/*.yml	Removed manual goss installation steps from CI workflows
gradle/verification-metadata.xml	Added checksums for gradle-download-task plugin dependency

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Adding quotes around environment variable values is inconsistent with the previous unquoted style and unnecessary for simple values. While functionally equivalent, this creates inconsistency in the Dockerfile's style. Consider keeping the original unquoted format unless there's a specific reason for the change.

Suggested change

	ENV BESU_GRAPHQL_HTTP_HOST="0.0.0.0"
	ENV BESU_GRAPHQL_HTTP_HOST=0.0.0.0

[Copilot]

The placeholder @DEFAULT_JVM_OPTS_25@ appears to be a template variable that should be replaced during the build process, but ${defaultJvmOpts} uses a different placeholder format. This inconsistency could lead to confusion. Ensure both placeholders follow the same convention or document why they differ.

Suggested change

	set DEFAULT_JVM_OPTS=${defaultJvmOpts}
	set DEFAULT_JVM_OPTS=@DEFAULT_JVM_OPTS_21@

[Copilot]

The placeholder @DEFAULT_JVM_OPTS_25@ uses a different format than ${defaultJvmOpts}. This inconsistency in placeholder syntax could indicate a template processing issue or incomplete implementation. Verify that both placeholders are correctly replaced during the build process.

Suggested change

	DEFAULT_JVM_OPTS=@DEFAULT_JVM_OPTS_25@
	DEFAULT_JVM_OPTS=${defaultJvmOpts25}

[Copilot]

The change from adduser to useradd alters the user creation tool. While useradd is more portable across distributions, adduser is a higher-level Debian/Ubuntu tool that was previously used. Ensure this change doesn't introduce compatibility issues with any scripts or tooling that might depend on the user creation method or expect specific group memberships that adduser automatically configures.

Suggested change

	useradd --uid 1000 --create-home --home-dir /opt/besu --shell /bin/bash besu && \
	adduser --uid 1000 --home /opt/besu --shell /bin/bash --disabled-password --gecos "" besu && \

[matkt]

I think @fab-10 is also looking at that