Getting error about using a 17 runtime, but dependences require Java 21

[davidmichaelkarr]

I have no idea whether this is a bug in m2e, I don't even know whether this is related to m2e, but I'm at a loss to explain why this is happening, and it seems to be related to m2e.

For background, I work on a number of Java 17 SpringBoot REST services that build with Maven. Our current version of our platform uses SpringBoot 3, although by default they use Jersey, not Spring MVC to implement the REST services. We've developed a new version that uses Spring MVC for the REST services.

All of the services using the existing released version using Jersey are working fine, both in mvn builds and in Eclipse. However, what I'm seeing is that any service using the new version, despite building fine with mvn, are getting errors like the following in Eclipse:

Incompatible .class files version in required binaries. Project 'platformpilotms' is targeting a 17 runtime, but is compiled against 'C:Users/dk068x/.m2/repository/org/glassfish/jersey/core/jersey-common/3.1.8/jersey-common-3.1.8.jar' (from the container 'Maven Dependencies') which requires a 21 runtime

The versions of dependencies are mostly set in our parent pom and bom. For this particular instance of the error, I tried manually adding a dependency for jersey-common, version 3.1.6, and that only changed the message to refer to a different dependency. I have a feeling if I tried specifying an older version of that dependency, it would just present the error for a different dependency.

I've looked at the pom file for jersey-common:3.1.8, and it does have some code that checks for which version of Java is being used, but I have no idea why Eclipse/m2e says it "requires a 21 runtime".

I could use any clue you could provide that could point me to a solution to this.

[laeubi]

I think you need to provide something one can actually open in an IDE to see the error from the error it is almost impossible to guess what causing this.

[davidmichaelkarr]

I understand. That will be pretty difficult.

However, I can provide a little more info that I've discovered since I posted this. I've been talking to other members of my team, and also trying some experiments.

Note that when I add the specific dependency for jersey-common 3.1.6, the next error that comes up is for logback-core v1.5.8. I looked in the logback-core 1.5.8 pom, and I saw this:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${maven-compiler-plugin.version}</version>
                <executions>

                    <execution>
                        <id>default-compile</id>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <configuration>
                            <release>${jdk.version}</release>
                        </configuration>
                    </execution>

                    <execution>
                        <id>java21-compile</id>
                        <phase>compile</phase>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <configuration>
                            <release>21</release>
                            <compileSourceRoots>
                                <compileSourceRoot>${project.basedir}/src/main/java21</compileSourceRoot>
                            </compileSourceRoots>
                            <multiReleaseOutput>true</multiReleaseOutput>
                        </configuration>
                    </execution>

                    <execution>
                        <id>default-testCompile</id>
                        <phase>test-compile</phase>
                        <configuration>
                            <testExcludes>
                                <exclude>**/COWArrayListConcurrencyTest.java</exclude>
                            </testExcludes>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

I'm not certain what this tells me. There is no setting of "jdk.version" in that pom, so I assume it expects to be set from outside this pom. It's curious that it has specific configuration for Java 21. I also note the information on this page: https://logback.qos.ch/news.html , which seems to imply that this version requires Java 21 at compile time.

I also note that when I manually set the compiler level for my project to 21, even though I'm using the java 17 library, the Eclipse error went away.

When I talked to my other team members about this, one person said that their default compiler level was 21, but they set it to 17 for all of our projects. In my Eclipse, my default compiler level is 1.8. This might explain why I'm seeing this error and they are not.

[laeubi]

Please note that due to how m2e internally works, it always uses the JDK of your running eclipse what is Java 21. It was once discussed to hook into profile activation and using the project JDK but this is not currently implemented an is maybe not trivial. Even more, as these profiles are most often used to change things that do not work on an older or newer JDK it is likely that even if we implement it it probably fails the build.

In my opinion it is rather bad practice to include the build config and profiles in a published pom anyways, this can produce hard to track effects like int his case.

[davidmichaelkarr]

@laeubi , that is interesting, but I'm not sure how that jives with what I've seen. I did get this particular issue to go away by making two changes in Eclipse. Remember that my code technically only requires Java 17. To make this Eclipse error go away, I changed the Java Compiler" in project properties to use Java 21. However, I then discovered that when I attempted to run any code in Eclipse, it complained that the code I was running with a Java 17 JVM was compiled with Java 21. So, I then changed the run configuration to Java 21, and now both the compiler and runtime are satisfied, for a project that actually only requires Java 17.

I also note that in my eclipse.ini file the "-vm" parameter is pointing to the internal JVM, which I think is Java 21. Are you saying I would have gotten different results if that was pointing to a different JVM, like a Java 17 JVM?

[laeubi]

As said without a runnable example its hard to guess, but if these dependencies have special handling for Java 21 jvms it is likely something is getting activated that the requires Java 21 (even if your code compiles for Java 17).

This could be

• enabling some compile options only valid for Java 21
• include some dependencies that require Java 21
• having some multi-release content for Java 21
• ... maybe more ...

What I would do here is to enable a Java 21 JVM for the project and select a target option 17, then you can see if running with Java 17 still works and it is just a build-time concern or if you are effectively depend on something for Java 21 at runtime (in wich case you might decide to upgrade your project to Java 21 source level as well).