Java version mismatch between JRE_CONTAINER and targetPlatform in M2E 2.0.0

[CsCherrYY]

steps to reproduce:

1. given sample project: https://github.com/mybatis/mybatis-3.git
2. open it in VS Code, with redhat.java extension 1.8.0 installed (which integrates m2e 2.0.0 snapshot).
3. after project imported, VS Code reports an error in Item record under package org.apache.ibatis.submitted.record_type.

java.lang.Record cannot be resolved to a type.

as we know, record should be available in Java 16 but not in Java 8.

4. check the generated .classpath file, the JRE_CONTAINER is set to JavaSE-1.8 VM.

classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8"

5. check the generated .settings/org.eclipse.jdt.prefs file, the target platform is set to Java 16 (which would be the expect source level since it's defined in https://github.com/mybatis/mybatis-3/blob/9da3467e96a03e8bd6e040139581a22ce5297c29/pom.xml#L449-L459)

org.eclipse.jdt.core.compiler.codegen.targetPlatform=16
org.eclipse.jdt.core.compiler.compliance=16
org.eclipse.jdt.core.compiler.source=16

if we rollback to redhat.java 1.6.0, which uses m2e 1.18.2, this issue disappears. The JRE_CONTAINER in .classpath file is JavaSE-16, and the value of pref org.eclipse.jdt.core.compiler.codegen.targetPlatform is also 16.

I think this issue might related to #597 which introduces a new limitation from maven-enforcer-plugin. But I'm not sure it's caused by the plugin or m2e itself. When debugging, the two environments seem to mismatch:

cc: @fbricon @rgrunber

[mickaelistria]

Can you please provide steps to reproduce with plain Eclipse m2e? Or even better, as a unit test for org.eclipse.m2e.jdt.tests ?

[rgrunber]

I am able to reproduce with :

Version: 2022-06 (4.25)
Build id: I20220704-0600
M2E - Maven Integration for Eclipse 2.0.0.20220705-1608 org.eclipse.m2e.feature.feature.group Eclipse.org - m2e

This does not occur with the 1.x m2e :

M2E - Maven Integration for Eclipse (includes Incubating components) 1.20.1.20220227-1319 org.eclipse.m2e.feature.feature.group Eclipse.org - m2e

I just had to add a Java 1.8 JDK to "Installed JREs" so that it may be detected (if needed). Otherwise, you'll see the runtime as JavaSE-1.8 (with an incompatible JDK underlying it which is a warning by default)

The pom file does have a profile :

    <profile>
      <id>16</id>
      <activation>
        <jdk>[16,)</jdk>
      </activation>
      <properties>
        <maven.compiler.testTarget>16</maven.compiler.testTarget>
        <maven.compiler.testSource>16</maven.compiler.testSource>
        <excludedGroups>TestcontainersTests,RequireIllegalAccess</excludedGroups>
      </properties>
    </profile>

Is this just a regression in detecting the Java runtime from the profile ?

[mickaelistria]

@rgrunber do you think you could turn this example into a test case for org.eclipse.m2e.jdt.tests?
@kwin any idea which part of the code too look at, that could be causing this inconsistency?

[kwin]

There are two different potential environment ids relevant:

m2e-core/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/AbstractJavaProjectConfigurator.java

Line 175 in 8b876a6

addJREClasspathContainer(classpath, buildEnvironmentId != null ? buildEnvironmentId : executionEnvironmentId);

. The getMinimumJavaBuildEnvironmentId() is used preferably and determined from the minimum Java enforced through m-enforcer-p while getExecutionEnvironmentId() is driven from maven-compiler-plugin settings (logic introduced in #590).

In this case the enforced Java version seems to be 8 (set via https://repo1.maven.org/maven2/org/mybatis/mybatis-parent/34/mybatis-parent-34.pom). The profile with id 16 doesn't set a value for property maven.compiler.source which is used in the maven-enforcer-plugin.

Not sure if the logic should be improved that always the higher execution id is being taken instead of the one from the m-enforcer-p first....

[mickaelistria]

getExecutionEnvironmentId() is driven from maven-compiler-plugin settings

And why does this return 16 here?

[kwin]

And why does this return 16 here?

Because the profile with id 16 sets the configuration for the test compile execution (

m2e-core/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/AbstractJavaProjectConfigurator.java

Line 790 in 8b876a6

protected List<MojoExecution> getCompilerMojoExecutions(ProjectConfigurationRequest request, IProgressMonitor monitor)

) accordingly.

[mickaelistria]

ah ok, I didn't notice this profile had an auto-activation set. But the properties it sets are for tests, so shouldn't those be ignored ?

[kwin]

All mojo executions are considered at

m2e-core/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/AbstractJavaProjectConfigurator.java

Line 612 in 8b876a6

for(MojoExecution execution : getCompilerMojoExecutions(request, monitor)) {

and the last one actually wins (i.e. determines the compiler options).

[mickaelistria]

All mojo executions are considered at

OK, so that's probably the root cause of the bug. The test executions should be skipped.

[kwin]

Not sure, if maven-enforcer enforces a lower version, but you have a profile (conditionally activated) setting the target of the compiler (not only for test) to a higher version you also run into this issue. So in general the JRE container should be the highest one from the different parameterisations.

[mickaelistria]

Not sure, if maven-enforcer enforces a lower version, but you have a profile (conditionally activated) setting the target of the compiler (not only for test) to a higher version you also run into this issue

That's not really the case here as only test config is overridden and there is no reason that the test config is used to derive main project settings. Moreover a pom setup that mixes different version in enforcer and main compilation would be inconsistent even from Maven POV, so no need to worry further about it in m2e.
Here the test compilation should be ignored, or only the default compilation considered. Other compilations are supplemental and manage things on a grain the doesn't map well in Eclipse m2e anyway.

[CsCherrYY]

Here the test compilation should be ignored, or only the default compilation considered. Other compilations are supplemental and manage things on a grain the doesn't map well in Eclipse m2e anyway.

@mickaelistria In this way, IIUC both the project's compliance and the JRE container of that sample project would be set to 1.8 since only the default compilation considered, right? And can we do something with the tests in source level 16?

[mickaelistria]

IIUC both the project's compliance and the JRE container of that sample project would be set to 1.8

Yes.

And can we do something with the tests in source level 16?

No. JDT cannot be configured to compile the sources from a given project with different compiler options (eg source level). Changing that would require a fair amount of work in JDT, to move the various options from project-scope only to source-folder scope. Then, when JDT can do it, m2e can leverage it.