Missing BREE for /org.eclipse.swt.win32.win32.x86_64/META-INF/MANIFEST.MF

[ewillink]

On a nominally Java 17 installation with Java 21 available importing org.eclipse.swt.win32.win32.x86_64 with sources leads to complation errors with post Java 17 syntax e.g. "sealed".

Please add an accurate BREE to the MANIFEST.MF.

Since the manifest editor is determined to winge about optional dependency problems that can reasonably be not problems

Execution environment is lower than one of the plug-in's dependencies (org.eclipse.core.runtime) which has an execution environment of JavaSE-17.

surely it should about a genuine problem?

[HeikoKlare]

Can you please provide a reproducer for the issue? I have set up a clean workspace with just the win32 fragment imported and cannot reproduce the reported issue. The fragment properly uses Java 21.

I do also not see why the reported error should occur:

• The fragment is only usable together with its host, which has BREE set to Java 21:

  eclipse.platform.swt/bundles/org.eclipse.swt/META-INF/MANIFEST.MF

  Line 26 in 7f9089e

  Bundle-RequiredExecutionEnvironment: JavaSE-21

• The fragment has a classpath configuration based on Java 21:

  eclipse.platform.swt/binaries/.classpath_win32

  Line 3 in 7f9089e

  <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21"/>

[ewillink]

On a nominally Java 17 installation with Java 21 available

i.e. Import Plugin gives a Java 17 JRE System Library for the plugin.

The fragment is only usable together with its host, which has BREE set to Java 21:

No. The plugin is useable on a Java 17 installation. I needed to add a 'printf' to debug the appalling speed of org.eclipse.pde.internal.ui.shared.FilteredCheckboxTree compared to the former org.eclipse.pde.internal.ui.launcher.FilteredCheckboxTree (see eclipse-ocl/org.eclipse.ocl#2424). I therefore had a fully functional installation able to support debugging and nested Eclipse. Import Plugin with sources should just work and allow me to add the required 'printf'. But no, the missing BREE gives very confusing diagnostics wrt 'sealed' classes that I had not even heard of. The absence is dishonest since an accurate BREE gives a sensible diagnosis and probably just works. since Java 21 was available, just not default.

[HeikoKlare]

Can you please share a complete, self-contained reproducer?

I've tried to reproduce the issue again, using an Eclipse SDK, changed default compliance to 17 and added a JDK 17 to be used by default (not sure if that's meant with a "norminally Java 17 installation"). But I am not able to produce any issue with that.

I tried multiple things:

• Created a plug-in project with dependency to SWT and used the "Import from source repository" feature:

• Imported the plugin with sources from according target definition:

In none of those cases I get any error.

[ewillink]

Unzip eclipse-SDK-4.37-win32-x86_64.zip
Start Eclipse, (Java 21 available/used by default).
Window-Preferences->Java->Install JRE to Install a Java 17 JVM and select it as the default.
import org.eclipse.swt.win32.win32.x86_64 with sources
=> no problems just as you observe
Window-Preferences->Java->Compiler to set compliance level to 1.8
=> 3752 errors
including many "Arrow in case statement supported from Java 14 onwards only" despite Java 17 being in use,

Maybe it isn't the BREE that is deceitful, rather the lack of support for 1.8 compliance or the lack of a diagnostic for the missing compliance.

[HeikoKlare]

Maybe it isn't the BREE that is deceitful, rather the lack of support for 1.8 compliance

Exactly, SWT is not compliant to Java 1.8. Setting compliance level to 1.8 manually will not work, no matter what you define as BREE for the fragment. I have to admit that I am not sure where that expectations is coming from.

Since we have not found any issue that requires BREE to be added to the SWT fragment as requested by the issue, I am closing it now.