[MTOOLCHAINS-58] Auto-detected Azul Zulu OpenJDK 8 is not found when selecting version 8, 1.8 or 1.8.0

[jira-importer]

Nils Breunese opened MTOOLCHAINS-58 and commented

I have Azul Zulu OpenJDK 8 installed, and it is indeed auto-discovered by toolchains:display-discovered-jdk-toolchains:

[INFO]   - /opt/local/Library/Java/JavaVirtualMachines/openjdk8-zulu/Contents/Home
[INFO]     provides:
[INFO]       version: 1.8.0_432
[INFO]       runtime.name: OpenJDK Runtime Environment
[INFO]       runtime.version: 1.8.0_432-b06
[INFO]       vendor: Azul Systems, Inc.
[INFO]       lts: true

I then want Maven to use Java 1.8 to build this project by adding this:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-toolchains-plugin</artifactId>
      <version>3.2.0</version>
      <executions>
        <execution>
          <goals>
            <goal>select-jdk-toolchain</goal>
          </goals>
          <configuration>
            <version>1.8</version>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

But then I get this error message:

org.apache.maven.plugin.MojoFailureException: Cannot find matching toolchain definitions for the following toolchain types:{version=1.8}
Define the required toolchains in your ~/.m2/toolchains.xml file.

I want to avoid developers having to maintain a toolchains.xml, and I've verified that this method does work for projects that use JDK 21 (also without a toolchains.xml, using auto-discovery).

I've also tried setting the version to 8 and 1.8.0, but that also didn't work.

Setting the version to 1.8.0_432 does work, but I don't want to force other developers to have this exact Java 8 build installed.

---

Affects: 3.2.0

1 votes, 2 watchers

[jira-importer]

Alex Galvin commented

I can confirm this issue also occurs with the latest Eclipse Adoptium JDK 8 on Linux.

I believe the root cause is that org.apache.maven.artifact.versioning.DefaultArtifactVersion.parseVersion doesn't correctly handle the legacy pre-Java 9 version scheme. It tries to parse 0_432 as an integer and falls back to exact string matching when it cannot.