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

[anthonyvdotbe]

When opening a Maven project which uses maven.compiler.source/target 13, the derived .classpath file uses J2SE-1.5 as its JRE container, instead of the expected JavaSE-12.

In other words: if the value for the Maven compiler properties is unsupported/unrecognized, it should default to the highest currently-supported version. This is much more likely to be what the user wants/expects. For example, with the new JDK release cadence (the first JDK 14 build is already released), it's more common (for me at least) to try out early-access JDK builds.

Environment

• Operating System: Windows 10 Pro 1809 (17763.557)
• JDK version: 12.0.1
• Visual Studio Code version: 1.35.1
• Java extension version: 0.46.0

Steps To Reproduce

1. unzip and open sample-maven-project.zip
2. let the extension generate the project files

Current Result

The .classpath file contains the following:

	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>

Expected Result

The .classpath file contains the following:

	<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>

[fbricon]

upstream issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=549312

[fbricon]

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

[EricZhangzf]

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>

[fbricon]

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.