Skip to content

Set maven.compiler.release unconditionally and drop the JDK profiles - #609

Draft
slachiewicz wants to merge 1 commit into
masterfrom
agent/release-from-target
Draft

Set maven.compiler.release unconditionally and drop the JDK profiles#609
slachiewicz wants to merge 1 commit into
masterfrom
agent/release-from-target

Conversation

@slachiewicz

@slachiewicz slachiewicz commented Sep 10, 2026

Copy link
Copy Markdown
Member

Related to #608. maven.compiler.release is now set from javaVersion unconditionally and the jdk8 and jdk9+ profiles are gone. Both consumers gate the option themselves: plexus-compiler only emits --release when the javac in use is 9 or newer, reading the version from the toolchain executable when forking, and the javadoc mojo checks its runtime version. That removes the toolchains flaw the old profile's comment admits (MNG-6943) and one moving part, with no behaviour change on JDK 9+.

The parent deliberately does not define maven.compiler.source or target next to release: maven-compiler-plugin 4.x forwards all three and javac rejects the combination, which is what #543 established and why #569 was withdrawn. This PR therefore does not fix the silent override in #608 on the 3.x plugin; the docs now say plainly that a project must override javaVersion, not source/target. A loud failure for the 3.x case would be an enforcer rule in a follow-up.

Verified with a child project against 40-SNAPSHOT on JDK 25, reading the javac command line:

plugin child sets result
3.16.0 on Maven 3.10.0-rc-1 nothing --release 8
3.16.0 maven.compiler.target 11 --release 8, unchanged from 39
3.16.0 javaVersion 17 --release 17
4.0.0-beta-5 on Maven 4.0.0-SNAPSHOT nothing success
4.0.0-beta-5 maven.compiler.target 11 option --target cannot be used together with --release, unchanged from 39
4.0.0-beta-5 javaVersion 17 success

Behaviour change only on JDK 8 builds: this POM no longer sets source and target there, so the compiler plugin's own default of 1.8 applies unless the project sets them. Measured on Zulu 1.8.0_504 with Maven 3.9.16, child setting nothing:

parent javac gets class file
39 -source 8 -target 8 major 52
this PR -source 1.8 -target 1.8 major 52

The compiler plugin's page says 3.13.0 "converts" release to source/target on JDK 8; MCOMPILER-582 added only ITs and docs, and its IT configures all three, so the conversion is the defaults coinciding. A child with javaVersion 7 cannot reach the difference: the parent's RequireJavaVersion rule rejects JDK 8 for range [7,) on 39 as well. The docs module builds.

This change was created with AI assistance.

@slachiewicz slachiewicz added enhancement New feature or request breaking Pull requests that break existing features waiting-for-feedback Waiting for 90 days until issues or pull request will be closed labels Sep 10, 2026
maven-compiler-plugin and maven-javadoc-plugin only pass release to a
JDK 9+ tool and fall back to source/target on JDK 8 by themselves, so
the jdk8 and jdk9+ profiles added nothing except the toolchains flaw
noted in their own comment (MNG-6943). The parent must not define
source or target next to release: maven-compiler-plugin 4.x forwards
all three and javac rejects the combination.

See #608
@slachiewicz
slachiewicz force-pushed the agent/release-from-target branch from be942d7 to 8986a0b Compare September 10, 2026 21:46
@slachiewicz slachiewicz changed the title Derive maven.compiler.release from maven.compiler.target Set maven.compiler.release unconditionally and drop the JDK profiles Sep 10, 2026
@slachiewicz

Copy link
Copy Markdown
Member Author

Branch rewritten. The previous version derived release from target and set all three properties, which fails on maven-compiler-plugin 4.x (see the table that was in the description). This version only sets maven.compiler.release from javaVersion and removes the two JDK profiles; the description is replaced accordingly.

This comment was created with AI assistance.

@github-actions github-actions Bot removed the waiting-for-feedback Waiting for 90 days until issues or pull request will be closed label Sep 10, 2026
@slachiewicz slachiewicz removed the breaking Pull requests that break existing features label Sep 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant