source level preferences are ignored when the project compliance is different from configured JDK

[CsCherrYY]

[provide a description of the issue]
source level preferences are ignored when the project compliance is different from configured JDK, even if the configured JDK is compatibile with the project compliance.

Environment

• Operating System: Windows 11
• JDK version: 17
• Visual Studio Code version:
• Java extension version: 1.12.0

Steps To Reproduce

1. set JDK 17 to default java.configuration.runtimes
2. git clone https://github.com/spring-projects/spring-petclinic, which has sourceCompatibility = 11 in its Gradle build script.
3. try to run spring-petclinic project

Current Result

java.lang.UnsupportedClassVersionError: org/springframework/samples/petclinic/PetClinicApplication has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

Expected Result

The applicaiton can be executed successfully

Additional Informations

[CsCherrYY]

AFAIK we now put the following options into project settings.

JavaCore.COMPILER_COMPLIANCE
JavaCore.COMPILER_CODEGEN_TARGET_PLATFORM
JavaCore.COMPILER_SOURCE

So this bug will affects those projects has different source level between that defined in build script (usually defined in build.gradle via sourceCompatibility or pom.xml via configuration.source) and java.configuration.runtimes.

e.g., the project specifies sourceCompatibility = 11 but the default java.configuration.runtimes points JavaSE-17. Since JavaSE-17 is compatible with 11, the project should be imported successfully and set JavaCore.COMPILER_COMPLIANCE = 11 in .settings. But this bug will override these settings. So the project source level will be always set to 17. Not sure if this bug affects a lot of people, and it's already fixed via eclipse-jdtls/eclipse.jdt.ls#2299.

cc: @rgrunber

[rgrunber]

Good catch here. I think the only long term solution is some kind of helper method we can start to use instead of manually calling getOptions(false), putting the new project-specific options in that map, and then setting the project options. I'm just thinking that this kind of bug is likely to be introduced in the future because the behaviour here is not obvious.