I've worked professionally on a fairly large SWT-based project. This project was started when Swing was slow and ugly so SWT probably seemed fresh. Also, having a native L&F was important in those days.

We had tons of problems and they where almost never easy to fix. Layouting in SWT is hard. Custom widgets are hard. SWT did not play nice with Swing/AWT on Linux so it would crash if you needed to use both. I remember I spent a lot of time getting automated testing working reliably (on mac) but eventually just gave up.

Things might have improved since I worked on this 7 years ago but I would not bet on it. SWT is basically a support library for Eclipse and therefore Eclipse is more or less the sole driver for any development.

I would rather just use Swing. Compared to when SWT was started Swing has evolved a lot and IMO the rationale for going with SWT does not exist anymore.

I haven't found the Layout system to be lacking or too difficult to deal with. My only issue with it is how verbose it feels sometimes. The operation of layout and layoutData can be a bit confusing.

You can always roll your own layout system using Control setBounds and moveAbove. I have toyed around with a custom layout system on top of SWT that uses Cassowary Constraints (in fact the imgur link in my other comment shows a sample).

As for custom widgets it really depends on how you want to do it since there are so many options. SWT can embed Swing or JavaFX components, so it allows the developer to make custom widgets in whichever tech they feel most comfortable. In this case I would stick with Swing since JavaFx can be a decently sized dependency, where as Swing is built into the jre.

The eclipse nebula project is also a pretty big repository of community made custom widgets. These can be really helpful for figuring out how to implement custom widgets in pure SWT. https://github.com/eclipse/nebula

I have never implemented automated testing with it though, bummer it was such a hassle.

Also SWT does grant access to a bit more of the underlying OS than Swing does with its org.eclipse.swt.internal.* package. For example I've had to embed a GLFW window inside a SWT window. This is done with the following api in GLFW: https://www.glfw.org/docs/3.3/group__native.html

Using the internal apis you to map GLFWs native window handle to something SWT understands pretty easily. Then it's just a matter of writing the platform specific code to reparent the GLFW window into App which was 3 or 4 lines of code per platform. Then once the GLFW app was inside the SWT App it was a matter of creating a dummy Composite that when resized would overlay the GLFW app. I don't believe this would have been possible in Swing without addition JNI. I know this is a pretty obscure use case, but the internal package can be extremely handy.

Lastly, SWT has a built in browser component that uses the OSs browser or there are optional embedded V8 and webkit packages. The feature set of SWT just blows other Java toolkits out of the water. Unfortunately, this does lead it to be a bit more complicated than the others. I'm sorry about your experience, but give it another whirl sometime maybe you'll be pleasantly surprised.

> his should allow you to develop a nice little statically link executable instead of deploying a jar if needed.

To save me the clone/compilation time, any approximate numbers of how small the binary is for a SWT app?

A super simple test on Ubuntu I did back in November got me a 14mb executable consuming about 23mb of ram and about 38mb once the app was full screened. I'm pretty happy with the size considering the smallest runtime I can get with jlink around 40mb. I have also found GraalVM devs to be very responsive to issues on Github.

I should note I am using Haxe here instead of pure Java, so a pure Java app might be a few kilobytes smaller.

Screenshot: https://imgur.com/3otiHA2

Curious - why would anyone choose SWT over Swing/JavaFX?

It used to be that Swing/AWT really sucked. The default theme on every platform (Metal) was really ugly. Everything was purple. The "native" look and feel was emulated (poorly). It was also very slow. That's the reasons why SWT was started in the first place. Swing would just not cut it for any app that wanted a nice UI.

Nowadays the situation is completely different. Swing looks and performs great compared to SWT. IMO it would make much more sense to just use Swing.

JavaFX never happened. People just went web instead. No one uses it and it's officially deprecated.

JavaFX was split out from the JRE and is now its own package[1]. It very much "happened" and there are plenty[2] of people using it.

If you are looking to build a fully themed app similar to a web app Swing or JavaFX are definitely the way to go. Swing still uses an emulated native look and feel and it is pretty decent. If you are planning on building something with real platform UI I would still go with SWT, especially if accessibility is on the table.

[1]https://openjfx.io [2]https://github.com/search?q=javafx&ref=simplesearch

JavaFX may be the most feature complete cross platform GUI framework after Qt. I have recently used it for a project and it tuned out much better than if I had used Swing.