Enforce JDK 21+ as minimum build JDK for multi-release JAR support

[Croway]

Summary

• Add requireJavaVersion [21,) to the existing enforce-java-version execution in maven-enforcer-plugin
• Update minimalJavaBuildVersion from ${jdk.version} (17) to 21

Motivation

camel-util uses multi-release JARs with a java-21-sources profile activated by <jdk>[21,)</jdk>. If Camel is built with JDK 17, the virtual thread classes under META-INF/versions/21/ are silently omitted — users running on JDK 21 would get JARs without virtual thread support.

Jenkinsfile.deploy defaults to jdk_17_latest, meaning daily SNAPSHOT deployments were built without virtual thread support.

This does not change the runtime requirement — Camel JARs remain Java 17 compatible. It only ensures the build JDK is high enough to compile the multi-release JAR layers.

The enforcer runs only when the full profile is active (not with -Dquickly), so fast local builds are unaffected. The Jenkinsfile.deploy fix ensures SNAPSHOT deployments use JDK 21.

Discussion thread: dev@camel.apache.org "Enforce JDK 21+ for building Camel"

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[apupier]

• Change Jenkinsfile.deploy default JDK from jdk_17_latest to jdk_21_latest

this mentioned change in the description is missing from the effectively modified files

[github-actions]

ℹ️ CI did not run targeted module tests (root project files changed).

---

⚙️ View full build and test results

[Croway]

• Change Jenkinsfile.deploy default JDK from jdk_17_latest to jdk_21_latest

this mentioned change in the description is missing from the effectively modified files

removed, on main it was already done

[gnodet]

Thanks for working on this, @Croway — the motivation is solid and ensuring SNAPSHOTs include the virtual thread classes is a real improvement.

A few suggestions, mostly around wording accuracy and one minor observation about the enforcer bypass scope. Nothing blocking.

Claude Code on behalf of Guillaume Nodet

[gnodet]

The "multi-release JAR" framing is a bit misleading — multi-release JARs are a Java 9 feature and work fine with older JDKs. What actually requires JDK 21 is the JDK 21-specific source code (virtual thread classes). The java-21-sources profile in camel-util/pom.xml activates on <jdk>[21,)</jdk> to compile those classes — it's the content, not the mechanism.

Suggested change

	<message>JDK 21+ is required to build Apache Camel. The multi-release JAR in camel-util requires JDK 21+ to compile virtual thread support. Building with JDK 17 produces JARs without virtual thread support.</message>
	<message>JDK 21+ is required to build Apache Camel. JDK 21-specific classes (e.g., virtual thread support in camel-util) are only compiled with JDK 21+. Building with JDK 17 silently omits these classes from the resulting JARs.</message>

[gnodet]

Same wording nit here:

Suggested change

	# Skip the enforcer which requires JDK 21+ (needed for multi-release JAR compilation).
	# Skip the enforcer which requires JDK 21+ (needed to compile JDK 21-specific classes).

[gnodet]

Note: -Denforcer.phase=none disables all enforcer rules on the JDK 17 build, not just the Java version check — this also skips the Maven version check (>= 3.9.6) and the banned-dependencies check. These are still verified on the JDK 21 leg, so it's not a gap in practice, but worth being aware of.

If you wanted a narrower bypass, the enforcer plugin doesn't support per-execution skip properties out of the box, so this is probably the simplest approach.

[gnodet]

Minor: this property is likely used by the ASF parent POM's own requireJavaVersion rule in the enforce-java-version execution. Combined with the explicit requireJavaVersion rule you're adding below (lines 200–203), the enforcer may evaluate two requireJavaVersion checks — both requiring JDK 21. Not harmful, but redundant.

You could either:

• Just update this property (and rely on the parent POM's rule), or
• Keep the explicit rule with the custom message and leave this property at ${jdk.version} (since the explicit rule supersedes it anyway).

Either way works — just a heads-up.