Skip to content

Migrate SWT to FFM #3605

Open
Open

Description

@vogella

We should migrate SWT GTK3 and GTK4 for use FFM. I already prototyped that and have a running Eclipse IDE based on https://github.com/vogella/eclipse.platform.swt/tree/ffm-migration.

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.

Image

Performance with FFM is currently worse compared to JNI, we are currently investigating.

Activity

  1. akurtakov commented on Sep 21, 2026

    @akurtakov
    Member

    I see porting starting with leafs like AWT,GLX, WebKit and going down .

  2. vogella commented on Sep 21, 2026

    @vogella
    ContributorAuthor

    AWT,GLX, WebKit

    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.

  3. HannesWell commented on Sep 23, 2026

    @HannesWell
    Member

    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.

  4. vogella commented on Sep 25, 2026

    @vogella
    ContributorAuthor

    GLX, WebKit and the AWT bridge now run on FFM on GTK3 in https://github.com/vogella/eclipse.platform.swt/tree/ffm-migration.

    Verification

    • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions