The starter parent of Spring Boot explicitly sets a property java.version.

<properties>
  <java.version>17</java.version>
  <resource.delimiter>@</resource.delimiter>
  <maven.compiler.release>${java.version}</maven.compiler.release>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  <spring-boot.run.main-class>${start-class}</spring-boot.run.main-class>
</properties>

Using this name for a property hinders your users to use the system property java.version set by the used virtual machine for checks and validations.

Please consider to use a different property name for Spring Boot 4.

Comment From: wilkinsona

I think I understand the issue but I don't find the following to be sufficient justification for making a breaking change:

Using this name for a property hinders your users to use the system property java.version set by the used virtual machine for checks and validations.

Can you please provide some concrete examples of how it is a hinderance?

The java.version property has been there since the first milestone twelve years ago. Perhaps something's changed in the Maven landscape such that it's now more of a problem? If so, please provide some details there too.

Comment From: obfischer

I noticed this problem when trying to use this property for a report and earlier then using it in messages for the Maven Enforcer Plugin.

I see the issue with changing such an important property.

Would it be an option to deprecate the usage of the property for now to to start using something like java-language-level?

Comment From: snicoll

I noticed this problem when trying to use this property for a report and earlier then using it in messages for the Maven Enforcer Plugin.

That sounds oddly specific for what you're asking for. Can you share a small sample that showcases the problem?

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: obfischer

Hi @snicoll,

here is the example usecase.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-enforcer-plugin</artifactId>
    <version>${maven-enforcer-plugin.version}</version>
    <executions>
        <execution>
            <id>enforce-java</id>
            <goals>
                <goal>enforce</goal>
            </goals>
            <configuration>
                <rules>
                    <requireJavaVersion>
                        <version>${java.version}</version>
                        <message>This project requires JDK 21. You are using ${java.runtime.version} via ${java.vendor} ${java.vm.name}. Please ensure you are using JDK ${java.version}.</message>
                    </requireJavaVersion>
                    <requireMavenVersion>
                        <version>${mavenVersion}</version>
                        <message>This project requires Maven ${mavenVersion}. You are using Maven ${maven.version}. Please ensure you are using the correct Maven version via the Maven wrapper. Run mvn wrapper:wrapper to ensure, that the configuration of the Enforcer plugin and the Maven Wrapper plugin are in sync.</message>
                    </requireMavenVersion>
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

In the message for the required Java version, I would like to use the property java.version instead of java.runtime.version.

Comment From: wilkinsona

We've discussed this today and we don't want to make a breaking change by renaming java.version. It's been this way since 0.5.0-M1 and this is the first time we've heard of it causing a problem. We can reconsider if we learn of many people who are adversely affected without a workaround.