Unexpected "JRE container" entry derived from pom.xml for Java SE 13 #951

Activity

1. fbricon

   added

   enhancement

   Maven

   upstream

   on Jun 20, 2019
2. fbricon

   self-assigned this

   on Jun 20, 2019
3. fbricon

   added this to the Mid July 2019 milestone on Jun 20, 2019
4. fbricon commented on Jul 16, 2019

   

   fbricon

   on Jul 16, 2019

   Collaborator

   More actions

   upstream issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=549312
5. fbricon commented on Jul 16, 2019

   

   fbricon

   on Jul 16, 2019

   Collaborator

   More actions

   The fixed m2e version is now consumed by jdt.ls (eclipse-jdtls/eclipse.jdt.ls@c966395)
6. fbricon

   closed this as completedon Jul 16, 2019
7. EricZhangzf commented on Jul 18, 2019

   

   EricZhangzf

   on Jul 18, 2019

   More actions

   Test this issue in my local machine, No matter what my local jdk version is(1.8, 11, 12), The .classpath file always:

   <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-12">
         <attributes>
               <attribute name="maven.pomderived" value="true"/>
         </attributes>
   </classpathentry>
   
8. fbricon commented on Jul 18, 2019

   

   fbricon

   on Jul 18, 2019

   Collaborator

   More actions

   Ok, I think I know what the issue is. We select the highest execution environment, but there might not be an actual jdk backing it.
9. fbricon

   reopened this on Jul 18, 2019
10. fbricon

    modified the milestones: Mid July 2019, End August 2019 on Jul 18, 2019
11. fbricon

    removed this from the End August 2019 milestone on Sep 2, 2019
12. fbricon

    removed their assignment

    on Jul 23, 2026
13. robstryker commented on Nov 2, 2026

    

    robstryker

    on Nov 2, 2026

    Contributor

    More actions

    Already fixed upstream!

    Found it exactly where Fred's hunch pointed.

    org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/AbstractJavaProjectConfigurator.java, method getExecutionEnvironment(String environmentId).

    Before the fix, the lookup was just an ID match with no viability check:

      for (IExecutionEnvironment environment : manager.getExecutionEnvironments()) {
          if (environment.getId().equals(environmentId)) {
              return environment;
          }
      }
      return null;
    

    So m2e would happily select e.g. JavaSE-12 purely because the ID matched the Maven compiler target, even if there was no actual installed JDK bound to that environment — exactly fbricon's diagnosis: "we select the highest execution environment, but there might not be an actual jdk backing it."

    The fix — commit aa212c49, Oct 11 2022, Konrad Windszus + Hannes Wellmann, closing m2e#842 ("Only select ExecutionEnvironments with at least one compatible VM installed"):

      IExecutionEnvironment environment = manager.getEnvironment(environmentId);
      if (environment != null && environment.getCompatibleVMs().length > 0) {
          return environment;
      }
      log.error("Failed to find a compatible VM for environment id '{}', falling back to workspace default", environmentId);
      return null;
    

    Now, when the chosen EE has zero compatible VMs, it falls back to null — which addJREClasspathContainer() turns into JavaRuntime.newDefaultJREContainerPath() (the workspace default JRE) instead of silently emitting a classpath entry for an environment with nothing backing it.

    Closing as fixed upstream.
14. robstryker

    closed this as completedon Nov 2, 2026