For invisible/unmanaged projects, JVMConfigurator.configureJVMSettings enables preview features (and sets the preview-report severity to ignore) when the project's Java version equals JavaCore.latestSupportedJavaVersion(), then persists that decision.
When a later jdt.ls release bundles a newer JDT compiler, latestSupportedJavaVersion() moves forward. A project that stays on the previously-latest JDK then has enablePreview=enabled at a non-latest compliance, which the compiler rejects with Preview features enabled at an invalid source release level .... That fails the whole workspace build, so nothing is compiled into the output folder.
configureJVMSettings is not re-run when an existing invisible project is reloaded, so the setting never self-heals. Renaming the project folder "fixes" it only because that forces a fresh import.
This recurs on every new Java version. Downstream report: redhat-developer/vscode-java#4420 — there the empty output folder surfaces as a ClassNotFoundException when loading a -javaagent whose Premain-Class lives in the output folder.
Proposal
On invisible project import, reset the preview options to their defaults when they look like they were auto-enabled by jdt.ls (enablePreview=enabled and preview-report severity ignore) and the project compliance is below latestSupportedJavaVersion(). Managed projects (Maven/Gradle), deliberate user settings (which keep the default warning severity) and projects legitimately on the latest JDK are left untouched.
This complements #3131/#3137, which only notifies the client about an incompatible preview setting but does not reconcile the value jdt.ls set itself.
For invisible/unmanaged projects,
JVMConfigurator.configureJVMSettingsenables preview features (and sets the preview-report severity toignore) when the project's Java version equalsJavaCore.latestSupportedJavaVersion(), then persists that decision.When a later jdt.ls release bundles a newer JDT compiler,
latestSupportedJavaVersion()moves forward. A project that stays on the previously-latest JDK then hasenablePreview=enabledat a non-latest compliance, which the compiler rejects withPreview features enabled at an invalid source release level .... That fails the whole workspace build, so nothing is compiled into the output folder.configureJVMSettingsis not re-run when an existing invisible project is reloaded, so the setting never self-heals. Renaming the project folder "fixes" it only because that forces a fresh import.This recurs on every new Java version. Downstream report: redhat-developer/vscode-java#4420 — there the empty output folder surfaces as a
ClassNotFoundExceptionwhen loading a-javaagentwhosePremain-Classlives in the output folder.Proposal
On invisible project import, reset the preview options to their defaults when they look like they were auto-enabled by jdt.ls (
enablePreview=enabledand preview-report severityignore) and the project compliance is belowlatestSupportedJavaVersion(). Managed projects (Maven/Gradle), deliberate user settings (which keep the defaultwarningseverity) and projects legitimately on the latest JDK are left untouched.This complements #3131/#3137, which only notifies the client about an incompatible preview setting but does not reconcile the value jdt.ls set itself.