[I/Y-Tests] Update to new macOS computers in RelEng Jenkins

[HannesWell]

Update the I/Y-build tests to run on the new macOS agents in the RelEng JIPP:

• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6621#note_6796846

Part of

• Reduce load on macosx-aarch64 machine in RelEng JIPP #3315

[HannesWell]

The execution of the minimal ant test-suite was already successful on both new mac machines.
At the moment the complete (all) test-suite is running, to ensure everything works fine for the daily I-build testing.
If that execution doesn't show regression, we can use the new machines immediately.

[HannesWell]

The Mac-ARM build looks quite good with only two failures:
https://ci.eclipse.org/releng/job/AutomatedTests/job/ep440I-unit-macosx-aarch64-java21-test-new-computer/6/
I'm not even sure if they are not random.

But on x86_64 the Mac tests have almost 3000 failures similar to

java.lang.NullPointerException: Cannot read the array length because "this.skinList" is null
	at org.eclipse.swt.widgets.Display.addSkinnableWidget(Display.java:570)
	at org.eclipse.swt.widgets.Widget.reskinWidget(Widget.java:436)
	at org.eclipse.swt.widgets.Shell.<init>(Shell.java:299)
	at org.eclipse.swt.widgets.Shell.<init>(Shell.java:271)
	at org.eclipse.e4.ui.bindings.tests.KeyDispatcherTest.testSendKeyStroke(KeyDispatcherTest.java:284)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

or

java.lang.NullPointerException: Cannot invoke "org.eclipse.swt.internal.cocoa.NSDictionary.objectForKey(org.eclipse.swt.internal.cocoa.id)" because "dictionary" is null
	at org.eclipse.swt.graphics.Device.getScreenDPI(Device.java:494)
	at org.eclipse.swt.graphics.Device.getDPI(Device.java:408)
	at org.eclipse.swt.graphics.Device.init(Device.java:625)
	at org.eclipse.swt.widgets.Display.init(Display.java:2396)
	at org.eclipse.swt.graphics.Device.<init>(Device.java:133)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:800)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:791)
	at org.eclipse.swt.widgets.Display.getDefault(Display.java:1545)
	at org.eclipse.e4.ui.tests.css.core.parser.CascadeTest.setUp(CascadeTest.java:56)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

https://ci.eclipse.org/releng/job/AutomatedTests/job/ep440I-unit-macosx-x86_64-java21-test-new-computer/4/#showFailuresLink

@HeikoKlare or @Phillipus, can this be a bug in the Mac impl for x86 or is this an error in the test setup?

[Phillipus]

@HeikoKlare or @Phillipus, can this be a bug in the Mac impl for x86 or is this an error in the test setup?

TBH I don't know. I can't test locally as I don't have an x86_64 Mac with macOS 15 (only 14).

Is it that the created binaries are linked to a later Mac SDK which is buggy on Intel? A lot of Mac SWT native code calls are deprecated.

[HeikoKlare]

In the console logs of the x64 execution, you find information /errors because of a headless environment. Those errors are not present in the aarch64 execution. That also fits to the test failures that show that Display initialization fails when accessing the deviceDescription of the NSScreen. It's sounds a bit strange that NSScreen can be initialized at all when we are in a headless environment, but I don't have any clue about the macOS API, so it might be that this is possible and a headless environment is still the cause.

2026-04-02 12:14:01.275 java[64095:3471847] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode.
     [java] Failed to start ClipboardTest
     [java] java.awt.HeadlessException: 
     [java] The application is not running in a desktop session,
     [java] but this program performed an operation which requires it.
     [java] 	at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:164)
     [java] 	at java.desktop/java.awt.Window.<init>(Window.java:553)
     [java] 	at java.desktop/java.awt.Frame.<init>(Frame.java:428)
     [java] 	at java.desktop/javax.swing.JFrame.<init>(JFrame.java:224)
     [java] 	at clipboard.ClipboardTest.<init>(ClipboardTest.java:63)
     [java] 	at clipboard.ClipboardTest.lambda$3(ClipboardTest.java:141)

[HeikoKlare]

For the Intel Jenkins node it also says "no login session": https://ci.eclipse.org/releng/computer/b9h15%2Dmacos15%2Dx86%5F64/

So my best guess is that this is a configuration issue of the Jenkins agent which does not run a user session but as a deamon without GUI.

[HannesWell]

So my best guess is that this is a configuration issue of the Jenkins agent which does not run a user session but as a deamon without GUI.

Sounds plausible and I already assumed an issue like this. Thanks for checking, I asked for help in at the help-desk:
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6621#note_6798085

[HannesWell]

A lot of Mac SWT native code calls are deprecated.

Indeed, I see seven deprecation warnings at the moment:

• Replace deprecated native methods in macOS implementation eclipse.platform.swt#3186

But it seems not related with the test failures as SWT currently works on recent macOS versions at user laptops (and in the ARM tests).

[HannesWell]

But it seems not related with the test failures as SWT currently works on recent macOS versions at user laptops (and in the ARM tests).

After the adjustments from Pawel the tests on mac x86_64 are almost all successful (just one failure), but for Mac on ARM we now have 182 failures that all seem to be related to parts of Eclipse not receiving the expected focus:
https://ci.eclipse.org/releng/job/AutomatedTests/job/ep440I-unit-macosx-aarch64-java21-test-new-computer/11/#showFailuresLink

I cannot tell if this is a configuration or code issue.

[HannesWell]

Thanks to Pawel from the EF IT team, the configuration of the new mac agents seems to work:
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6621#note_6798470

Submitting this, so that we can verify it with real I-build tests.