[abstractdog]

What changes were proposed in this pull request?

Switch the runtime of Hive's Docker images from Java 21 to Java 25:

• packaging/src/docker/Dockerfile: eclipse-temurin:21-jdk-ubi9-minimal → 25-jdk-ubi10-minimal
• packaging/src/kubernetes/Dockerfile: 21-jre-ubi9-minimal → 25-jre-ubi10-minimal
• standalone-metastore/packaging/src/docker/Dockerfile: 21.0.3_9-jre-ubi9-minimal → 25-jdk-ubi10-minimal
• itests/tez-yarn-it Hadoop image:
  • Tez AM and task containers now run on a JDK 25 at /opt/jdk25; CONTAINER_JAVA_HOME is updated to match.
  • The base image moves from apache/hadoop:3.4.2 to 3.4.3. On JDK 24+ (JEP 486), the UserGroupInformation in Hadoop 3.4.2 calls Subject.getSubject, which throws UnsupportedOperationException, so the Tez AM fails at startup.
  • TezYarnClusterContainer now also tags the image it builds as hive-it-hadoop:latest, the name docker-compose.yml refers to. Without that tag, compose either used a stale local image or tried to pull one from a registry.
  • The built image is now removed after the run: it is built with deleteOnExit=true, and stop() removes the latest tag so Ryuk can delete it.

The Maven build JDK (CI workflows, Jenkinsfile, README prerequisites) stays on Java 21.

Why are the changes needed?

To run Hive in Docker on the current Java LTS release.

Does this PR introduce any user-facing change?

Yes. The published Hive and standalone Metastore Docker images now run on Java 25 with a UBI 10 base.

How was this patch tested?

mvn test -Pitests,tez-yarn -pl itests/tez-yarn-it, starting with no hive-it-hadoop images present locally. The test passed, the Tez AM launched with JAVA_HOME=/opt/jdk25, and no hive-it-hadoop images were left after the run.

[deniskuzZ]

Thanks! +1, with two optional suggestions.

Verified:

• I've been running Hive on eclipse-temurin:25-jdk-ubi10-minimal (RHEL 10.2, glibc 2.39, JDK 25.0.5) with Hadoop 3.4.3 for over a week on a 12-node TPC-DS 10 TB cluster: HS2, HMS, LLAP and a standalone Tez AM, with no JVM flags beyond the existing --add-opens. No restricted-method warnings in the logs, so --enable-native-access is not needed.
• apache/hadoop:3.4.3 does ship Java 11 (JAVA_VERSION=jdk-11.0.28+6; 3.4.2 shipped Java 8), so the new comment in the tez-yarn-it Dockerfile is accurate.
• The new tagging fixes a real bug on master: docker-compose.yml runs hive-it-hadoop:latest, while buildHadoopImage() builds hive-it-hadoop-<uuid>, so the test never ran the image it built.

Suggestions (non-blocking):

1. TezYarnClusterContainer: instead of re-tagging the built image as hive-it-hadoop:latest and removing that tag in stop(), the compose file could take the image from the environment, image: ${HIVE_IT_HADOOP_IMAGE}, with new ComposeContainer(composeFile).withEnv("HIVE_IT_HADOOP_IMAGE", hadoopImage). This also works with withLocalCompose(false), since testcontainers 1.21.4 passes the env to the compose container.
   It fixes the same bug without a shared mutable tag: two runs on one Docker host would re-point latest under each other. untagHadoopImage() and its DockerException handling would also go away, because the image keeps a single tag and Ryuk can delete it.
2. standalone-metastore/packaging/src/docker/Dockerfile: this moves from a pinned JRE (21.0.3_9-jre-ubi9-minimal) to an unpinned JDK (25-jdk-ubi10-minimal), while the operator image uses 25-jre-ubi10-minimal. If the metastore image doesn't need the JDK tools, 25-jre-ubi10-minimal keeps it smaller and matches the operator image. If it does (e.g. jcmd for thread dumps, as in the main image), a line in the description would help.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud