AOT-related goals are failing when using java 17

[nedelva]

On a brand new Micronaut Application created with Launcher web application, the mn:aot-sample-config goal fails with this output: mn-aot-sample-config output.txt

When running mvn package with AOT enabled, the mn:aot-analysis generates pretty much the same thing: mn-aot-analysis output.txt TL;DR:

Caused by: java.lang.UnsupportedClassVersionError: io/micronaut/maven/testresources/TestResourcesLifecycleExtension has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0

How to reproduce: generate a Micronaut application using Launcher. Here's a screenshot of the choices:

Then run either one of the AOT-related goals. [Tested on a Windows 10 Family OS machine, with Java 17 and Maven 3.9.6]

[nedelva]

I added the project to my GitHub account for your convenience: aotdemo.

Funny thing is, the error does not reproduce on a MacBook Pro machine 😟

[alvarosanchez]

You are running with Java 8 which is not supported by Micronaut 4.

[nedelva]

@alvarosanchez I am sorry but you were too quick to dismiss it. I am NOT using Java 8 , I am using Java 17.

Tagging with "cannot reproduce" is just lazy, since you can reproduce it easily on a Windows machine if you bother to clone the aotdemo project and try to build it on a Windows machine.

Very dissapointed with the way you handled it.

[alvarosanchez]

@nedelva no need to be so disrespectful.

If you care enough to read your own details, you will find that:

io/micronaut/maven/testresources/TestResourcesLifecycleExtension has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0

So even if you think you are running with Java 17 (class file version 61.0), you are not. You are running with Java 8 (version 52.0).

Besides, mn:aot-sample-config is tested on CI with Java 17 and Java 21 and even on Windows.

But if this weren't enough, I did take the time to try to reproduce it locally (look at the timestamps):

Nevertheless, you always have the chance to provide more context and/or request for this issue to be reopened. I didn't lock this conversation.

Next time, I would appreciate it if you could show more respect for an OSS contributor.

[nedelva]

@alvarosanchez I think my objections still stand. What you are showing me is

1. a demo project build on Mac (NOT on a Windows machine) -- I also mentioned that the issue does not reproduce on a Mac
2. a few builds of the plugin itself on Docker instances (NOT the same thing as using the plugin to build!)

None of the above disproves my claims. I urge you to actually try to build the sample project on a Windows machine and you will see that the issue does occur indeed.

[alvarosanchez]

Why you keep ignoring this?

this version of the Java Runtime only recognizes class file versions up to 52.0

You are running with Java 8. But if you insist on making this more embarrassing, here's a screenshot of your project running on a Windows machine:

[nedelva]

My submissions for the image gallery contest 🥇

The project settings, where you can see I use JDK 21 in fact:

Also don't forget that is not possible to execute the build with java 8 since the POM specifies the properties

    <jdk.version>17</jdk.version>
    <release.version>17</release.version>

See here what running from command prompt gives me. First, I set the JAVA_HOME environment variable:

The exact command you ran:

But I think the clue to the puzzle can be seen in the second image of the run (see my red underline)

@alvarosanchez Here's the trick question for you: If on a Windows machine there are several Java JDK versions installed, which one is picked when the plugin invokes the command java? 😈

(I admit, I unintentionally threw you on a wrong path by forgetting to mention that I have SEVERAL JDKs installed on my machine)

[alvarosanchez]

JAVA_HOME is not enough. Your PATH is pointing to a Java 8 installation.

Running mvn --version (or even java -version) will tell you this info.

[nedelva]

Ok, I will save you the trouble to find out yourself what's going on exactly. See, on my machine there was also Java 8 installed via the MSI installer. This thing modifies the Windows registry so I did not need to use _JAVAHOME nor the PATH variables to invoke java on the command prompt.

Because of this, when the 'java' was invoked by the plugin, it was picking Java 8 because there was NOTHING on the PATH variable to point to a different version.

I remedied the situation by

1. Uninstalling the Java 8 JDK using the Control Panel and
2. I added several full paths to the bin directory for each of the JDKs into the user's PATH variable. Now invoking java picks up whichever version is found first (here 21):

I am happy that I have gotten past the issue and found a workaround. I still believe that the plugin is buggy since it's behavior is erratic: you can make it to call a different Java version than the one is used by the project (like 8 in my case). But I am certain you could easily spot now the trouble with current arrangement.

[alvarosanchez]

I'm glad you finally found out why you were running with Java 8 👍

I still believe that the plugin is buggy since it's behavior is erratic: you can make it to call a different Java version than the one is used by the project (like 8 in my case)

This has nothing to do with the plugin. Maven (and Gradle, and pretty much all Java applications) will run with the java version that you have configured on your system, and not having any java in the search PATH is the root of your problems. Properly setting your development environment is out of scope here.

The JDK version in your POM is only meaningful for the Maven Compiler Plugin. This plugin does nothing with it. It allows you to do things like compile with JDK 21 but produce 17 bytecode.

Switching JAVA_HOME and PATH to the desired JDK version is what everybody do (and the reason why things like SDKMAN exist), but even if you are unable/unwilling to set them properly, you can still configure Maven Toolchains