native-maven-plugin throws error: gu.cmd' tool was not found.

[alexFilichkin]

Description
native-maven-plugin throws error: gu.cmd' tool was not found. It happens because in Graalvm jdk21 gu was removed. oracle/graal#6855**

System Info (please complete the following information):

• OS: [e.g. Windows]
• GraalVM Version [e.g. graalvm-jdk-21.0.0 ]
• Java Version [e.g. 21]
• Plugin version [e.g. native-maven-plugin:0.9.27]

Additional context

native-image --version
native-image 21 2023-09-19
GraalVM Runtime Environment GraalVM CE 21+35.1 (build 21+35-jvmci-23.1-b15)
Substrate VM GraalVM CE 21+35.1 (build 21+35, serial gc)

[kpoalses]

Happens under macOS as well.
GraalVM for JDK 21: OpenJDK Runtime Environment GraalVM CE 21+35.1 (build 21+35-jvmci-23.1-b15)
Maven plugin: org.graalvm.buildtools:native-maven-plugin:0.9.27

mvn -Pnative package
Results in Failed to execute goal org.graalvm.buildtools:native-maven-plugin:0.9.27:compile-no-fork (build-native) ...elided... 'gu' tool was not found. This probably means that JDK at is not a GraalVM distribution.

Noted this on GraalVM Slack:
https://graalvm.slack.com/archives/CNBFR78F9/p1695985908702449

[fniephaus]

I can't seem to reproduce this. What JAVA_HOME and/or GRAALVM_HOME (if any) are you using?

[kpoalses]

I can't seem to reproduce this. What JAVA_HOME and/or GRAALVM_HOME (if any) are you using?

Ah, therein lies the rub! I use jenv to switch between JDK versions, and this works fine for almost anything else built by grade, maven and leiningen. It seems Graal Native Tools needs JAVA_HOME to be managed as well.

For future reference by others suffering PEBCAK, fixed by using

jenv enable-plugin export

The GraalVM build tools are now happy, thanks.

[fniephaus]

Good to know there's a workaround, @kpoalses. Nonetheless, we'd like to make sure the plugins are as easy to use as possible, so it'd be good for us to know what exactly went wrong on your end. What JAVA_HOME/GRAALVM_HOME combination did not work?

[kpoalses]

Good to know there's a workaround, @kpoalses. Nonetheless, we'd like to make sure the plugins are as easy to use as possible, so it'd be good for us to know what exactly went wrong on your end. What JAVA_HOME/GRAALVM_HOME combination did not work?

For clarity, without the export plugin, jenv only updates the JDK shims to point at the correct JDK binaries (java, java, jlink etc), it doesn't set JAVA_HOME at all, and other tooling (mvn, gradle, etc) infer the JAVA_HOME from the binary path, so for example:

/Library/Java/JavaVirtualMachines/graalvm-community-openjdk-21+35.1/Contents/Home/bin/java
would have an inferred JAVA_HOME of /Library/Java/JavaVirtualMachines/graalvm-community-openjdk-21+35.1/Contents/Home

and /Library/Java/JavaVirtualMachines/temurin-20.jdk/Contents/Home/bin/java would have an inferred JAVA_HOME of /Library/Java/JavaVirtualMachines/temurin-20.jdk/Contents/Home

In my problem case, although Maven was able to infer JAVA_HOME to be /Library/Java/JavaVirtualMachines/graalvm-community-openjdk-21+35.1/Contents/Home, and would happily compile, execute tests etc, the GraalVM Native tooling did not infer the JAVA_HOME, and went on to complain about gu.

With JAVA_HOME explicitly set (manually or using the jenv plugin) the GraalVM native tooling behaves correctly.

As I said, entirely my fault, although the error message regarding 'gu' tool not being found was a bit misleading - perhaps an outright complaint about lack of JAVA_HOME or GRAALVM_HOME not being set would be more helpful.

[fniephaus]

As I said, entirely my fault, although the error message regarding 'gu' tool not being found was a bit misleading - perhaps an outright complaint about lack of JAVA_HOME or GRAALVM_HOME not being set would be more helpful.

Yes, that sounds reasonable. The error message should remind users to check their JAVA/GRAALVM env vars, I'll take care of that. Thanks for the feedback!