@httpdigest Ok und danke für die Ausformulierung. Was ich konkret meinte, ist, das Eclipse mal kurz WPF unterstützte, aber noch nie Richtung UWP geschaut hat. Ich meine damit also eher die GUI-Toolkits, die auf win32 aufsetzen. Das, was die Eclipse Foundation für SWT verwendet, ist ziemlich Low Level und... veraltet. Daher meine Bemerkung bzgl. des Alters.
@busgi Vielleicht mal etwas Vorweg: JavaFX ist, wie Swing - und im weiteren Sinne auch diverse Frameworks für Hybrid-App-Entwicklung für mobile Geräte, in erster Linie plattformunabhängig. Das heisst, es geht darum, mit einer Code-Basis eine indentisch aussehenden Anwendung auf verschiedene Plattformen zu bringen. (Das da jetzt natürlich am Ende ein plattformspezifischer Renderer existiert, steht auf einem anderen Blatt, aber bei Java ging es stehts darum, einen Code überall laufen zu lassen, nicht ob die Runtime darunter selbst nicht doch nativen Kram machen muss.)
Daher ist es schwierig, native Komponenten (z.B. OLE/ActiveX) in so eine Anwendung zu integrieren. Im Moment z.B. gibt es bei der Cross-Plattform-App-Lösung Flutter einiges an arbeiten am Unterbau, um genau das zu unterstützen. Bei JavaFX steht das IMHO nicht auf der Roadmap.
Bei SWT dagegen geht das, da SWT "nur" eine plattformunabhängige Abstraktion vom darunterliegenden Toolkit (win32 auf Windows, Cocoa auf Mac (glaub ich) und GTK 2/3 auf Linux) darstellt. Was man bei SWT also am Ende bekommt ist eine mit Java angesteuerte native Anwendung (von der GUI her). JavaFX und Swing dagegen bieten "lediglich" ein natives Frame (hier auch wieder platformspezifisch), dass du mit dem jeweiligen Renderer mit nicht-nativen Inhalt füllst. Sozusagen.
Aber noch etwas anderes: Du hast neulich schon gewisse Problem bei der Tabelle gehabt - die Integration nativer Komponenten setzt dem ganzen da noch einmal eins oben drauf! IMHO wäre das im Moment eh etwas zu sehr nach den Sternen gegriffen, denke ich.