Swing Prototype Summary

This summary belongs to prototyping work on evaluating technology candidates to be used for a new implementation of the Eclipse Standard Widget Toolkit (SWT) layer which is (as far as possible) independent from the operating system. In comparison to the existing SWT implementations that use OS libraries and widgets, a technology for a potential new implementation should already deal with and hide OS specifics, such that an SWT implementation does not have to care about the underlying OS anymore. To this end, the technology must be capable of providing the same features as the union of the existing SWT implementations. In addition, it should be an enabler for further improvement, such as better customizing and theming options, better web integration via web assembly, sophisticated multi-monitor HiDPI support and the like.

The goal of the prototyping phase is not to completely implement the SWT layer with a specific technology, but to provide insights about whether such an implementation is feasible and reasonable. This includes a founded estimation whether or with how much effort this will be possible technology-wise, which developer capabilities are required for development and maintenance, and for what kind of improvements the technology might be an enabler. The results should serve as a means to make an educated decision on whether one or multiple technologies are suitable for an actual implementation of SWT using those technologies and, in case multiple fit, which of them fits best.

Technology

Java's Swing.

Reasons

• Multiplatform.
• Standard in Java:

  • Well maintained.

  • Well documented.

  • Extensive community (expertise):

    • 81.000+ questions in StackOverflow tagged with: swing (vs. 6.000+ tagged with swt for comparison).
    • Relevant almost all over the world according to Google Trends .

    

  • Long life expectancy: (quote from the Java SE Spring 2024 Roadmap Update)

    As announced in the Java client roadmap update in 2020, Swing and AWT remain core Java SE technologies. They continue to receive bug fixes and updates on all LTS supported releases and mainline, as warranted by the evolution of the operating systems supported by Oracle Java.

• Customizable: supports themeing and different themes exist (e.g., FlatLaf Darcula).
• Supports HiDPI by setting the DPI Awareness to Per-Monitor (v2) out of the box.
• Supports vectorized icons.
• Initial (unfinished) implementation available:
  • SWTSwing by nu11ptr (GitHub) (based on SWTSwing (SourceForge))

Details

• Part of the Java Foundation Classes (JFC).
• Delivered as part of the JDK (e.g. OpenJDK).
• Architectural details:
  • Follows the MVC pattern.
  • Single-Threaded.
  • Allows for themeing and "hot replacement" (i.e. in runtime).
  • Can embed AWT.

Required Skills

• No special skills required, it's 100% Java.

Contributors

Prototyping work has been conducted by:

• Denis Ungemach (SAP)
• Michael Schneider (SAP)
• Federico Jeanne (Vector Informatik)
• Heiko Klare (Vector Informatik)

Total time invested was about 80 hs or 2 work weeks for 1 person.

Results

• Swing port (branch): swing.

Achievements

Working

• Buttons: Push, Check, Radio.
• StyledText:
  • Setting the font style, foreground and background colors of StyledText (Snippet163).
• StyleRange (Snippet211).
• Only show Window (Snippet1).
• Textbox + Button (Snippet116).
• Demonstrator with multiple SWT Display instances (SnippetDoubleDisplay).
• SnippetExplorer.
• CustomControlExample.
• Embedding of AWT components:
  • Embed Swing/AWT in SWT (Snippet135).
  • Embed a JTable in SWT without flicker (Snippet154).
• Themeing.

Working partially

• Browser: custom implementation without CSS support.
• ControlExample: the application starts and looks good but some functionality is missing e.g. :
  • The Tooltips tab does not display any tooltip even though tooltips do work (they appear when one hovers over buttons in other tabs).
  • The DateTime widget is not implemented (yet) so its tab is not useful.
• Eclipse SDK product: the application starts but it has some quirks e.g. :
  • Icons (images) are not visible: it's not a problem with ToolItem because those already display images in a normal SWT application e.g. in a modified version of Snippet47.
  • Views can not be properly minimized/maximized.
  • Some views have the wrong size.
  • Several errors about resources not being properly disposed are thrown upon ending the application.

Not working (yet)

The following topics are not working yet but there is no reason why it shouldn't work, it's just a matter of implementing the functionality.

• StyledText:
  • Drag text between two StyledText widgets (Snippet210).
  • Draw a box around text (Snippet244).
  • Use margins in StyledText (Snippet316).
• The DateTime widget is not implemented.

Insights

• Decent performance: was to be expected (see SWT vs Swing performance comparison).
• Instantiating a second Display is not a problem.
• Several basic stuff were already working (many widgets) but some were left unfinished, calculating the right size of some components like CoolBars and ExpandBars being the most notorious.
• Activating the anti-aliasing for fonts and graphics is already possible and it can be seen in the GraphicsExample snippet (screenshots below).
• The initial implementations (in SourceForge and in GitHub) weren't developed in years which means there was either little appeal to this approach or some impediment that we (yet) don't know about.
• Sub-pixel rendering is not supported out of the box by Swing. The reason for this is that Swing is cross-platform and sub-pixel rendering is highly dependent on the hardware. While there are RenderingHints like VALUE_TEXT_ANTIALIAS_LCD_HRGB and VALUE_TEXT_ANTIALIAS_LCD_HBGR that can be provided to the Graphics2D, these do not assure true sub-pixel rendering because they depend on details like the LCD display having a specific pixel disposition (BGR / RGB).

First attempt at the Swing port and community reception

(Summary of this issue and this thread).

Years ago, the community asked and voted for the Swing port and provided good arguments for it:

• Portability: using it in environments where SWT was not yet supported
• Usage in secure environments: getting approval to use DLLs in such environments was difficult but since Swing was pure Java, native DLLs wouldn't be necessary
• Avoiding OS-specific issues: Java and Swing would deal with those
• Skinability (a.k.a. themeing)
• Performance improvements in the Linux port: back then, SWT was using GTK 2 and some users had reported that the UI was slow.

The port was never officially adopted by the SWT maintainers though. Arguments against it were:

• Big effort
• The mandate of SWT was always "efficient, portable, native".

There were some technical reasons pointed out too but it mostly boiled down to "it might be doable but the SWT team will not look into it, it's just not worth it". No blocking technical issues were mentioned back then.

The community responded by supporting the project SWTSwing, but that project was never officially adopted by Eclipse.org and therefore it didn't get widely adopted. Even though the project made it possible to run SWT applications on top of Swing, apparently it never got to let a full Eclipse application run with it.

Risks

• There are no automated performance tests or any kind of benchmarking so the good performance of the Swing port is really only subjective. Moving forward, a clear definition of what "performance" means might be needed.

• The current custom implementation of the Browser (CBrowserImplementation) lacks basic functionality like CSS support.

• Embedding native window handles is not easy out of the box and it requires further investigation.

• Accessing platform-specific features (like tray icons, native dialogs, etc.) in Swing often requires workarounds or additional libraries like JNI.

• Swing’s JTable, JTree, and JList can handle large datasets, but managing large amounts of data efficiently can require more custom coding.

• It is unclear (at least to me) whether or not new features will be added to Swing in the future or if it will only be maintained i.e. bugs will be fixed and security updates will be applied.

Conclusion

Based on the amount of effort put into this PoC and the fact that most of it was achieved during a 1-day session in the SAP Hackathon in June, Swing has proven (as expected) to be a good candidate to offer a single multi-platform port for SWT. Lots of the main functionalities are working after the PoC, some are still not (the most important being the Browser), performance is acceptable (no flickering while working with the UI) and the fact that there is a foundation to start with makes it a low cost alternative. There are though some caveats that require a deeper analysis, like the quality of the fonts which is (currently) visibly inferior to the quality seen in the OS-dependent ports. One last point is the fact that even though Swing is and will remain part of the JDK for the foreseeable future that doesn't necessarily mean that new features will be added to it, so there's the risk of Swing being outdate in the coming years (this doesn't necessarily mean that it will look outdated since Swing supports themeing).

Final Assessment: Swing looks like a promising alternative to provide a single port of SWT because of its low risks, ease of distribution and because it continues to receive bug fixes and updates. The fact that is 100% Java code also makes it easier to find the necessary expertise in the market. We suggest to keep looking into it and extend the PoC period in order to gain deeper insight regarding open points like improving/replacing the Browser, performance for complex UIs and, most importantly, the integration of native window handles.

Appendix

Screenshots

Snippet163: StyledText.

Snippet113: the size of the scrolled composite is wrong.

ControlExample.

SnippetExplorer with themeing FlatLaf Darcula.

Snippet128: custom Browser with no CSS support.

Bare RCP application (not the sdk.product): icons are missing.

Double display (SnippetDoubleDisplay): works fine.

Fonts sharpness: snapshot of the GraphicsExample running on the Swing port without using anti-aliasing for fonts (above) and using it (below).

Graphics sharpness: snapshot of the GraphicsExample running on the Swing port without using anti-aliasing for graphics (above) and using it (below).

HiDPI support: Here you can see the SnippetExplorer on a 200% monitor using 2 different DPI Awareness modes: System and Per-Monitor (v2).

Interesting links

• SWTSwing by nu11ptr (GitHub).
• SWTSwing (SourceForge).
• Relationship to SWT.
  • SWT vs Swing performance comparison.
• Add Swing as a supported platform for SWT (Eclipse Issue Tracker).
• Swing port is coming - Lotus assists IBM! (Eclipse Forum).