The java builder should use the correct compiler compliance to build the project

@fbricon

Environment

Operating System: MacOS and Windows 10
JDK version: any
Visual Studio Code version: 1.41.x or 1.42.0-insider
Java extension version: 0.57.0

Steps To Reproduce

Have java.home to point to JDK 13, and launch the language server.
Have Java 8 installed in the machine.
Configure multiple JDKs in the user setting.

    "java.configuration.runtimes": [
        {
            "name": "JavaSE-13",
            "path": "C:\\Program Files\\Java\\jdk-13.0.1"
        },
        {
            "name": "JavaSE-1.8",
            "path": "C:\\Program Files\\AdoptOpenJDK\\jdk-8.0.242.08-hotspot"
        }
    ]

Open an eclipse Java 8 project 26.environmentVariables.zip
.

Current Result:

See the screenshot above, the PROBLEMS viewlet reports a warning on the project: "The compiler compliance specified is 13 but a JRE 1.8 is used". This means the classfile built by the ls is targeting to java 13, that would make it not able to be launched in JDK 8.

Besides, the debugger has fixed a bug microsoft/vscode-java-debug#753 about using the project's Java runtime to launch the application. The latest debugger would fail at this case.

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: EnvrionmentVariable has been compiled by a more recent version of the Java Runtime (class file version 57.0), this version of the Java Runtime only recognizes class file versions up to 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

Expected

The language server should generate the compatible .class files with the project's Java Runtime.

// @fbricon @snjeza

@testforstephen

@testforstephen

Have java.home to point to JDK 13, and launch the language server.

That causes Java LS to use the workspace Compiler Compliance level 13.
Your project inherits it and reports the warning.
You should configure your project by adding 26.environmentVariables/.settings/org.eclipse.jdt.core.prefs with following contents:

eclipse.preferences.version=1
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.8
org.eclipse.jdt.core.compiler.compliance=1.8
org.eclipse.jdt.core.compiler.release=disabled
org.eclipse.jdt.core.compiler.source=1.8

or use the following settings:

 {
      "name": "JavaSE-1.8",
      "path": "C:\\Program Files\\AdoptOpenJDK\\jdk-8.0.242.08-hotspot",
      "default": true
}

@snjeza

@snjeza Most of users don't have knowledge about the .settings. If project compiler compliance setting is undefined, how about auto assign a compiler compliance compatible with the project JRE_CONTAINER during eclipse project importer?

@testforstephen

@testforstephen I agree. @fbricon What do you think?

I had the same problem when not using the properties:

   <properties>
     <maven.compiler.source> XX </maven.compiler.source>
     <maven.compiler.target> XX </maven.compiler.target>
   </properties>

As I'm experimenting with Java 14 the way to configure the java version in maven has changed to:

<plugin>
  <artifactId> maven-compiler-plugin </artifactId>
  <configuration>
    <release>14</release>
  </configuration>
</plugin>

Thus, from the point of view of maven, it is no longer necessary to use maven.compiler.target/source, however, for VS Code it is still necessary to specify these properties so that it correctly interprets the version of Java used in the project.

Then, I solve my scenario using this two settings above.

Well hello there :)

It does seem that VSCode-Java stuggles to properly detect and apply maven compiler settings from maven's pom.xml.

I've tried a number of configurations, and no matter what I do, the Java version defaults to 1.6 in org.eclipse.jdt.core.prefs. It can, however be manually configured, as pointed out earlier in this thread.

This matter is made worse because the vscode-java plugin will overwrite manually configured settings back to 1.6 when updating project configurations, making this supremely disruptive.

I also had to to set configurations manually in the .classpath file manually:

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

@lincolnthree

@lincolnthree could you attach your project or pom.xml?

Update. Looks like adding a newer version of the maven-compiler-plugin and setting the following configuration has gotten things mostly working:

			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>3.8.1</version>
				<configuration>
					<source>1.8</source>
					<target>1.8</target>
				</configuration>
			</plugin>

The broken version was maven-compiler-plugin:3.2.0

Perhaps a warning could be issued if using an obsolete/incompatible version of the maven-compiler-plugin.

I have the same problem on a project with mixed JDK 8 and JDK 11/17 for its module.
Seems solved by applying same solution as in #1290 (comment)

e.g.: not enough

  <properties>
    <maven.compiler.release>17</maven.compiler.release>
  </properties>

but this works:

  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
  </properties>

I am using

  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.10.1</version>
        </plugin>

After updating to redhat.java 1.51.0, Maven compiler settings defined in pom.xml are no longer respected when a system-wide Java 1.8 installation is present.

Although the project is configured to use a newer Java version (e.g., via in the maven-compiler-plugin), VS Code resets the project runtime to Java 1.8 after cleaning or reloading the project.

I have tried various configuration options, but after performing a clean or reimport, the project compiler settings are always reverted to Java 1.8.

VS Code Settings (settings.json)

    "java.configuration.detectJdksAtStart": false,
    "java.jdt.ls.java.home": "D:\\Users\\Programs\\Java",
    "java.configuration.runtimes": [
        {
            "name": "JavaSE-21",
            "path": "D:\\Users\\Programs\\Java",
            "default": true
        }
    ]

Project Settings (pom.xml)

<properties>
    <java.version>17</java.version>
    <maven.compiler.release>17</maven.compiler.release>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>
...
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.14.1</version>
    <configuration>
        <release>17</release>
        <source>17</source>
        <target>17</target>
    </configuration>
    ...
</plugin>

@p3t3r5

@p3t3r5 I can't reproduce the issue. Can you attach your pom.xml?(feel free to anonymize it)

@p3t3r5 I can't reproduce the issue. Can you attach your pom.xml?(feel free to anonymize it)

Thank you for trying to reproduce the issue.
After analyzing our pom.xml, I noticed something that might be relevant.

I am not entirely sure why we have custom executions defined in the compiler plugin configuration, but after removing the executions section, the compiler settings are applied correctly after clean/recompile and the bytecode version is properly set to 17.

This did not cause any issues with redhat.java 1.50.0. The problem started after upgrading to 1.51.0.

SOLVED

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-compiler-plugin</artifactId>
	<version>3.14.1</version>
	<configuration>
		<release>17</release>
		<source>17</source>
		<target>17</target>
	</configuration>
	<!-- <executions>
		<execution>
			<id>default-compile</id>
			<phase>none</phase>
		</execution>
		<execution>
			<id>default-testCompile</id>
			<phase>none</phase>
		</execution>
		<execution>
			<id>java-compile</id>
			<phase>compile</phase>
			<goals>
				<goal>compile</goal>
			</goals>
		</execution>
		<execution>
			<id>java-test-compile</id>
			<phase>test-compile</phase>
			<goals>
				<goal>testCompile</goal>
			</goals>
		</execution>
	</executions> -->
</plugin>

OK so then there's a good chance the regression was caused in upstream m2e by eclipse-m2e/m2e-core@cd5feb8. We'll need to investigate more.

In 1.50.0, the extension embeds org.eclipse.m2e.jdt_2.4.101.20250727-0653.jar
In 1.51.0, it embeds org.eclipse.m2e.jdt_2.5.0.20251112-1507.jar

Navigation Menu

Repository navigation

The java builder should use the correct compiler compliance to build the project #1290

Environment

Steps To Reproduce

Current Result:

Expected

VS Code Settings (settings.json)

Project Settings (pom.xml)

SOLVED

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The java builder should use the correct compiler compliance to build the project #1290

Description

Environment

Steps To Reproduce

Current Result:

Expected

Activity

snjeza commented on Feb 20, 2020

testforstephen commented on Feb 21, 2020

snjeza commented on Feb 21, 2020

marlonpatrick commented on Jul 24, 2020

lincolnthree commented on Dec 19, 2020

snjeza commented on Dec 19, 2020

lincolnthree commented on Dec 19, 2020

lincolnthree commented on Dec 19, 2020

lincolnthree commented on Dec 19, 2020

tarilabs commented on Dec 16, 2022

p3t3r5 commented on Feb 16, 2026

VS Code Settings (settings.json)

Project Settings (pom.xml)

fbricon commented on Feb 16, 2026

p3t3r5 commented on Feb 16, 2026

SOLVED

fbricon commented on Feb 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions