You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not yet covered: GTK4, WebKit, GLX and the AWT bridge on Linux, Win32 and Cocoa.
Also not yet done: C.java and Callback.java to FFM in the product build as they live in shared folders that the win32 and cocoa builds also compile, and those have no FFM version. That's why the product build still loads the JNI libraries.
Good news is, IDE starts without any failures and according to the SWT tests, our vogella SWT harness and our vogella Eclipse harness the IDE is pixel identical.
Performance with FFM is currently worse compared to JNI, we are currently investigating.
I see porting starting with leafs like AWT,GLX, WebKit and going down .
I agree that that makes sense.
Ideally we'd also port library by library in order to avoid recompiling the remaining parts of a library multiple times. Practically it would be good to at least focus to handle binary by binary with as few steps per binary as possible.
Another important question is also how to handle the tools we have at least for macOS and Windows (don't know if there are also tools for Linux), to generate the JNI files. We could port them to generate FFM bindings instead. Maybe based on jextract.
Or we just replace these tools by corresponding shell scripts plus a few java classes for example to cleanup the code generated by jextract.
Furthermore I think it would make sense to perform the migration only when at ideally all three OS implementations has some part done so that all benefit from it and we make sure a consistent BREE requirement for all fragments exist.
I've also had a chat with @HeikoKlare about this a few weeks ago and one thought was to keep SWT on Java-21 for one more release and focus on all other parts of the platform first that can benefit from FFM, which also matches the plan that has been discussed at multiple occasions.
The comparison between the JNI and FFM builds found no differences.
The full JUnit suite gives identical outcomes on both builds: 4,062 passed. The 78 failures and 11 aborts are the same on both and come from running headless.
The Browser tests give the same outcomes (201 passed) with the three JNI libraries removed from the library path.
A GLCanvas and SWT_AWT test program gives the same output as JNI in normal, -Xint and -Xcomp modes, with no warnings under -Xcheck:jni.
5,000 AWT handle lookups under garbage-collection pressure returned the same handle every time.
The Tycho build of the SWT bundle, the x86_64 GTK fragment and the tools is green.
Activity
akurtakov commentedon Sep 21, 2026
I see porting starting with leafs like AWT,GLX, WebKit and going down .
vogella commentedon Sep 21, 2026
All things neither I nor my clients are using (except WebKit which is used by some of my clients), so not my personal order of porting.
HannesWell commentedon Sep 23, 2026
I agree that that makes sense.
Ideally we'd also port library by library in order to avoid recompiling the remaining parts of a library multiple times. Practically it would be good to at least focus to handle binary by binary with as few steps per binary as possible.
Another important question is also how to handle the tools we have at least for macOS and Windows (don't know if there are also tools for Linux), to generate the JNI files. We could port them to generate FFM bindings instead. Maybe based on jextract.
Or we just replace these tools by corresponding shell scripts plus a few java classes for example to cleanup the code generated by jextract.
Furthermore I think it would make sense to perform the migration only when at ideally all three OS implementations has some part done so that all benefit from it and we make sure a consistent BREE requirement for all fragments exist.
I've also had a chat with @HeikoKlare about this a few weeks ago and one thought was to keep SWT on Java-21 for one more release and focus on all other parts of the platform first that can benefit from FFM, which also matches the plan that has been discussed at multiple occasions.
vogella commentedon Sep 25, 2026
GLX, WebKit and the AWT bridge now run on FFM on GTK3 in https://github.com/vogella/eclipse.platform.swt/tree/ffm-migration.
Verification