Pin Java toolchain to the JDK found by find_package(Java)

[hyoklee]

Close #6559.

Problem

When HDF5_BUILD_JAVA=ON, HDF5 discovers Java twice, through two CMake
mechanisms with opposite search precedence, and never reconciles them:

1. find_package(Java) in CMakeLists.txt → Java_JAVA_EXECUTABLE,
   Java_JAVAC_EXECUTABLE, Java_JAR_EXECUTABLE, Java_VERSION_STRING
2. project(HDF5_JAVA C Java) in java/CMakeLists.txt → CMAKE_Java_COMPILER,
   CMAKE_Java_RUNTIME, CMAKE_Java_ARCHIVE

FindJava.cmake puts JAVA_HOME in HINTS, which outrank $PATH, and
honors both $ENV{JAVA_HOME} and -DJAVA_HOME= via CMakeFindJavaCommon.cmake.
CMakeDetermineJavaCompiler.cmake puts $ENV{JAVA_HOME}/bin in PATHS, the
lowest-priority slot, searched after $PATH, and ignores the CMake variable
JAVA_HOME entirely.

So when JAVA_HOME and $PATH name different JDKs, the two diverge. HDF5 then
evaluates the FFM/JNI version gate in java/CMakeLists.txt

if (Java_VERSION_STRING VERSION_GREATER_EQUAL "25.0.0")

against one JDK while compiling and testing with another.

This is not macOS-specific. On Windows with PATH → JDK 11 and JAVA_HOME →
JDK 20, current develop reports:

-- Found Java: .../OpenJDK/jdk-20/bin/java.exe (found version "20.0.0")
-- Building HDF5 Java with JNI implementation (Java 20)

CMAKE_Java_COMPILER ".../Microsoft/jdk-11.0.16.101-hotspot/bin/javac.exe"
CMAKE_Java_RUNTIME  ".../Microsoft/jdk-11.0.16.101-hotspot/bin/java.exe"
TEST_JAVA=.../Microsoft/jdk-11.0.16.101-hotspot/bin/java.exe

macOS merely makes it lethal rather than latent: both lookups land on the
/usr/bin stubs, which are not JDKs but dispatchers that re-select one from
$JAVA_HOME at each invocation. javac and java can therefore resolve to
different JDKs inside a single build, and every Java test dies at class load:

-- JAVA COMMAND:  /usr/bin/java; -Xmx1024M ...
Exception in thread "main" java.lang.UnsupportedClassVersionError:
  test/TestH5Eparams has been compiled by a more recent version of the Java
  Runtime (class file version 69.0), this version of the Java Runtime only
  recognizes class file versions up to 65.0

(69 = JDK 25, 65 = JDK 21.)

Fix

Propagate the toolchain from find_package(Java) before the Java language is
enabled, filling each variable independently.

Independently matters. The guard in CMakeDetermineJavaCompiler.cmake is
if(NOT CMAKE_Java_COMPILER) and it closes only after the runtime and archive
lookups, so a caller doing

cmake -DJAVA_HOME=$JAVA_HOME -DCMAKE_Java_COMPILER=$JAVA_HOME/bin/javac ...

suppresses the other two lookups entirely and ends up with an empty
CMAKE_Java_RUNTIME and an empty TEST_JAVA in the generated CTest files — so
ctest invokes no JVM at all. Filling the three in one at a time keeps an explicit
override working while still completing the toolchain.

Verification

Windows, PATH → JDK 11, JAVA_HOME → JDK 20: compiler, runtime, archiver
and TEST_JAVA now all resolve to JDK 20, matching the Java_VERSION_STRING
that drove the implementation choice.

macOS 26.5.2 arm64 (shared / OpenMPI / Fortran / Java), JAVA_HOME → JDK 25:
the same build went from 95 failing Java tests to 0.

GitHub macos-26, three configurations — image-default JAVA_HOME;
JAVA_HOME → 25 with only -DCMAKE_Java_COMPILER passed; and JAVA_HOME → 25
with JDK 21 first on $PATH — all produce a single-JDK toolchain and 255/255
Java tests passing. This includes the ctest -D ExperimentalConfigure path,
where CMake is re-run in a shell whose JAVA_HOME has reverted to the image
default; the pin survives because -DJAVA_HOME= is a cache entry and
CMakeFindJavaCommon.cmake consults the CMake variable before
$ENV{JAVA_HOME}.

Notes

• Behavior is unchanged when JAVA_HOME and $PATH already agree, which is the
  common case; the added block only fills variables that are otherwise unset.
• An explicit -DCMAKE_Java_COMPILER= / -DCMAKE_Java_RUNTIME= still wins.
• Not addressed here: if JAVA_HOME is unset entirely on macOS,
  find_package(Java) itself falls through to $PATH and finds /usr/bin/java,
  so the toolchain is pinned to a stub. It is at least pinned consistently, but
  hardening that would mean rejecting /usr/bin runtimes or resolving through
  /usr/libexec/java_home at configure time.
• No release_docs/RELEASE.txt entry is included; happy to add one if that is
  wanted for a build-system fix.

[github-actions]

Review Checklist

This PR touches the following areas. Each needs a sign-off
from its listed owners before merging.

• CMakeLists.txt ✅ — @lrknox

✅ All areas have been signed off.

[jhendersonHDF]

Rather than override the CMAKE_Java_XXX variables, we should probably remove Java from the list of languages specified in the Java-specific CMakeLists files and also push down this find_package call into those files. See the last comment on https://gitlab.kitware.com/cmake/cmake/-/work_items/18174. Also, the CMake documentation doesn't list support for Java as a language: https://cmake.org/cmake/help/latest/command/project.html#options.