Add JDK 25 support with TornadoVM JDK25 and dual-JDK build profiles

[mikepapadim]

Description:

Summary

This PR introduces JDK 25 support alongside the existing JDK 21 build, updating the build system, CI workflows, and runtime scripts to handle both JDK targets.

• Dual-JDK Maven profiles: Refactor pom.xml to introduce jdk21 and jdk25 profiles with dynamic versioning via a property, allowing independent builds and Maven Central releases for each JDK target.
• TornadoVM JDK25 integration: Update llama-tornado submodule and set_paths script to point to the TornadoVM JDK25 distribution, and align environment variable references from TORNADO_SDK to TORNADOVM_HOME for
  consistency.
• CI/CD updates: Enhance the Maven Central deployment workflow to support multi-JDK matrix releases and improve job summary output. Update the release preparation script to correctly modify the property in
  pom.xml.
• Housekeeping: Add .flattened-pom.xml to .gitignore to prevent accidental commits of generated flatten-plugin artifacts.

Test plan

• Build successfully with -P jdk21 profile
• Build successfully with -P jdk25 profile
• Verify set_paths correctly sets TORNADOVM_HOME for both JDK targets
• Run Maven Central deployment workflow dry-run for both JDK profiles
• Confirm .flattened-pom.xml is not tracked by git after a build

[stratika]

LGTM

[Copilot]

Pull request overview

This PR adds JDK 25 support to the GPU-accelerated LLaMA3 project alongside the existing JDK 21 build, introducing a sophisticated dual-JDK release strategy using Maven profiles and CI-friendly versioning. The changes enable independent Maven Central releases for each JDK target while standardizing environment variable naming from TORNADO_SDK to TORNADOVM_HOME.

Changes:

• Introduced dual-JDK Maven profiles (jdk21 and jdk25) with dynamic versioning via flatten-maven-plugin
• Updated environment variable references from TORNADO_SDK to TORNADOVM_HOME across scripts and CI workflows
• Enhanced CI/CD workflows to support matrix-based multi-JDK deployment to Maven Central

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
pom.xml	Added JDK profiles with auto-activation, CI-friendly versioning, flatten-maven-plugin, and conditional compiler args for Vector API
set_paths	Renamed TORNADO_SDK to TORNADOVM_HOME environment variable
llama-tornado	Updated Python script to use TORNADOVM_HOME instead of TORNADO_SDK
.gitignore	Added .flattened-pom.xml to prevent tracking generated flatten-plugin artifacts
.github/workflows/prepare-release.yml	Changed version update mechanism from mvnw versions:set to sed for CI-friendly version property
.github/workflows/deploy-maven-central.yml	Added matrix strategy for deploying both JDK21 and JDK25 artifacts
.github/workflows/build-and-run.yml	Updated all TORNADO_SDK references to TORNADOVM_HOME

---

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

[Copilot]

The environment variable has been renamed from TORNADO_SDK to TORNADOVM_HOME, but the README.md file still contains references to TORNADO_SDK (lines 92-93, 105-106, 119). Additionally, set_paths.cmd (Windows script) still uses TORNADO_SDK on lines 12 and 15. These files should be updated to use TORNADOVM_HOME consistently across all scripts and documentation to prevent user confusion.

Suggested change

	# Ensure TORNADOVM_HOME is set and valid before updating PATH
	if [ -z "${TORNADOVM_HOME}" ]; then
	echo "[ERROR] TORNADOVM_HOME is not set. Please export TORNADOVM_HOME to your TornadoVM installation directory before sourcing this script." >&2
	return 1 2>/dev/null || exit 1
	fi
	if [ ! -d "${TORNADOVM_HOME}" ]; then
	echo "[ERROR] TORNADOVM_HOME ('${TORNADOVM_HOME}') does not point to a valid directory." >&2
	return 1 2>/dev/null || exit 1
	fi

[Copilot]

The removal of --add-modules=jdk.incubator.vector from the javadoc plugin configuration may cause javadoc generation to fail on JDK 21 when the code uses Vector API classes. Since the Vector API is still incubating in JDK 21, the javadoc generation needs access to the module. Consider conditionally adding this flag based on the active profile, similar to how it's handled in the compiler plugin configuration.

[Copilot]

The comment states "Vector API is stable in JDK25; add-modules jdk.incubator.vector not needed", but all Java source files still import from jdk.incubator.vector. If the Vector API is still in the incubator module in JDK 25, then --add-modules=jdk.incubator.vector would still be required for compilation. Please verify that the JDK 25 profile actually compiles successfully without the add-modules flag, or add it to the jdk25 profile if needed.

[mairooni]

LGTM