Initiative 31 Final Report: proving an OS-agnostic future for SWT
The Eclipse Platform has been powering the Eclipse IDE and a large ecosystem of Eclipse RCP applications for more than two decades. It is one of those technologies that quietly keeps critical tools running, in software engineering teams and across many industries, every day.
But the reality of building and maintaining desktop tooling has changed. Operating systems evolve faster, UI stacks become more complex, and expectations around rendering quality, theming, HiDPI support, and cross platform consistency keep rising. At the same time, the cost and complexity of maintaining OS-specific integrations keeps increasing.
That is why, in 2021, a group of companies came together to create the Eclipse IDE Working Group: to collectively ensure the long term sustainability of the Eclipse Platform, also known as Eclipse RCP, and of the Eclipse IDE built on top of it.
By 2024, the Eclipse Standard Widget Toolkit (SWT) had become one of the most strategic areas to address. SWT remains a cornerstone of the Eclipse Platform, but it also comes with a structural challenge: it relies on three separate, OS-specific implementations for Windows, Linux, and macOS. That means high maintenance effort, complex behavioural differences, and limited control over look and feel and customisability.
This is the context in which Initiative 31 was launched.
Initiative 31 is an evaluation project supported by the Eclipse IDE Working Group, focused on the long term sustainability of Eclipse SWT, the Eclipse Platform, and the products built on top of them.
🕰️ 2024 was the year of exploration, selection, and early prototypes:
🚀 2025 became the year of the “big prototype”: turning the chosen approach into a functional demonstrator on GitHub that can launch and operate the Eclipse SDK while rendering SWT widgets through the graphics library Skia.
✅ What has been achieved
Initiative 31 has concluded with a successful demonstrator implementation showing the feasibility of reimplementing SWT in an OS-agnostic way and mitigating relevant risks.
As a result, a productively usable implementation is no longer a matter of conceptual or technological uncertainty, but rather of execution effort and engineering capacity.
All artefacts, including the demonstrator and the final report, are publicly available here: https://github.com/swt-initiative31/
🧠 TLDR
📌 SWT can be reimplemented in an OS agnostic way.
📌 Skia plus custom-implemented widgets is a validated and promising direction.
📌 The Eclipse SDK can be launched and operated on the demonstrator.
📌 Key risks were addressed: complex widgets, event handling, performance, GC capabilities.
📌 The path to production is now mainly a question of investment, not feasibility.
🔬 What has been learned, at a high level
Initiative 31 started with a broad evaluation of the technology landscape, looking for candidates that could support a new SWT implementation with minimal OS dependence, while preserving SWT’s API and key behaviour.
Three candidates were prototyped: GTK, Swing, and Skia.
As the work progressed, the direction converged towards Skia combined with custom-implemented widgets. This was primarily driven by:
⚙️ Productivity and debuggability: the custom widget approach is largely pure Java, making iteration fast and accessible for SWT developers.
🧱 Incrementality: widgets and behaviours can be replaced step by step while keeping SWT-based products running.
🔁 Reduced dependency risk: Skia is “just” a rendering engine. The SWT side can expose a lean interface, and the rendering backend can be exchanged if needed.
🎛️ Future enablement: a custom widget stack is a natural foundation for more consistent cross-platform behaviour, improved theming, and deeper customisability, without being locked into OS widget constraints.
The detailed decision and rationale, including why GTK and Swing were dropped and what was learned from them, are covered in the report.
🛡️ What risks have been addressed
A key goal of Initiative 31 was not only “make widgets appear”, but also to validate that the difficult parts are feasible.
The demonstrator and targeted prototypes specifically addressed several high risk areas, including:
🧾 Complex widgets: feasibility was demonstrated with StyledText, adapted to work with Skia to a high degree. The result is not perfect yet, but the main risk was retired.
🧠 Event handling: feasibility of OS-independent event handling was evaluated in a dedicated prototype, demonstrating that fully custom input and interaction handling is achievable.
🖌️ Graphics Context capabilities: significant SWT GC functionality was implemented on top of Skia, validating the idea of a rendering engine as an interchangeable backend behind SWT’s graphics layer.
⚡ Performance characteristics: dedicated prototypes validated decent performance in hardware accelerated mode and via OS buffer rendering paths. The demonstrator is not performance optimised yet, but the feasibility and potential are confirmed.
For the deep technical detail, the report is the best entry point: https://github.com/swt-initiative31/documents/blob/main/report/overall_report.md
🧱 A realistic migration path: incrementality works
One of the most important outcomes is that this work can be done incrementally.
Throughout the initiative, the goal was to keep SWT based products running while progressively replacing widgets and behaviours. The SWT Control Examples and the Eclipse SDK were used as continuous checkpoints.
This is critical because it makes a future transition practical for the Eclipse ecosystem. It enables progressive testing, and controlled risk management, rather than a disruptive rewrite. While gradual adoption of incremental changes for products in production is technically possible, it is still important to note that this is not recommended due to the mixture of different technologies. Among others, this can especially lead to performance drawbacks until one technology completely replaces the other.
🧭 What happens next
Initiative 31 was initiated and driven by Eclipse IDE Working Group members on a voluntary basis, without central funding. The capacity available was sufficient to deliver prototypes, mitigate key risks, and build the demonstrator, but not to produce a full, production-ready SWT implementation.
The final report includes a realisation plan that outlines the main steps to move from demonstrator to production quality, and provides a capacity estimate.
📊 The minimum estimate for a full implementation usable by most consumers is 20 person years.
To deliver in a timeframe around 2 years, the recommendation is to start only if at least 10 full time equivalent developers can be committed.
This is a significant investment, but it is now a measurable engineering plan. The core uncertainty has been retired.
🔧 Immediate follow-up work, even without a full rewrite
The report also identifies work that can deliver value even if a full OS agnostic SWT implementation is not started immediately:
🎯 Skia-based GC in SWT A Skia based graphics backend can improve performance for custom drawn content, for example GEF diagrams. Work exists in a dedicated repository: https://github.com/swt-initiative31/skija-canvas
🧩 Contributing strong custom widgets back into SWT Some custom widget implementations may become superior to native ones and could be contributed back to existing SWT implementations as emulated widgets or targeted improvements.
📣 Call to action
If your organisation relies on Eclipse SWT or Eclipse RCP, or if you care about the long-term sustainability of open source developer tooling, now is a good time to engage, feel free to contact me for more information.
Initiative 31 has reduced the risk: feasibility is proven, the technical direction is validated, and the work ahead is well understood. What is needed now is a critical mass of companies and contributors willing to fund and staff the effort.
🎤 This work and the realisation plan will be presented by Heiko Klare at Open Community for Tooling, part of Open Community Experience #OCX 2026 in Brussels, Belgium, taking place 21 to 23 April 2026. 📝 Registration is open here
🔗 Links
🗂️ Initiative 31 GitHub organisation, final report, prototypes: https://github.com/swt-initiative31/
📌 Skia demonstrator: https://github.com/swt-initiative31/prototype-skija
📌 Skia based GC work: https://github.com/swt-initiative31/skija-canvas
📄 Context article (JavaPro, July 2025): https://javapro.io/2025/07/16/a-new-generations-chance-to-shape-the-future-building-the-next-great-java-ide-in-open-source/
🙏 Acknowledgements
Thanks to everyone who participated in and contributed to Initiative 31. This project was driven openly, collaboratively, and on a voluntary basis, and it produced results that materially improved the long term sustainability outlook for SWT and the Eclipse Platform.
