Recently, I started pondering the thought of getting one of those fancy new MacBooks to replace my aging, 800Mhz TiBook. Since Eclipse has been my IDE of choice, I had to wonder; what is the state of SWT for Mac OS X on Intel? Luckily, support is planned for Intel Mac in version 3.2, which is still a beta. Incidentally, the Intel builds are currently unavailable until the Eclipse folks can get their mits on an Intel Mac in order to perform any builds.
When an OS makes an architecture shift like Apple has, it reveals the shortcomings in the SWT design. SWT depends on native code to make calls to underlying windowing system. Sure, Swing also does this on some level, but each JDK implementation has Swing support. And with the exception of GCJ/GNU Classpath, I have yet to see a JDK implementation ship without a full Swing implementation. In Apples case, when OS X on Intel came out, it supported Swing from the get go. Since SWT uses a non-standard widget implementation, it will take some extra time to get that toolkit up to speed. Furthermore, it will take some additional time after the initial release to work the all the kinks out.
But even when all of Intel support is taken care of, Mac users still won’t have access to things like the SWT to AWT Bridge, and we’re just beginning to see the Eclipse Visual Editor working on Mac OS X (But again, no real mention of how these might play out on Intel). But the next big shift comes not from an OS with a small user base, but the OS with the largest user base. The current SWT implementation on Windows is based on Win32 API/MFC which is being phased out in favor of WinFX. Granted, my knowledge of Windows programming is minimal, but from what I gather is that MFC-based applications will still function under Vista. However, it’s unclear if these applications can take advantage of Vista’s new services and if they’ll have a franken-app appearance like OS 9 apps did under Mac OS X’s Classic environment? And the bigger question, how will SWT based apps look and work under Vista?
WIth this kind of volatility with a UI toolkit, I have some trouble understanding why someone would choose the Eclipse RCP platform to develop applications on? Sure, Eclipse RCP applications on Windows are probably just swell. But if the application is going to just work on well on Windows only, why bother writing it in Java in the first place? I already mentioned the limitations of some of the SWT on Mac OS X, but things get event better on Linux. The SWT FAQ tells an awful lot. My SWT on GTK favorite: no printing. I could go on and on, but I think the FAQ speaks for itself. Sure Swing has its issues, but it certainly has been consistent, warts and all. The same can’t be said for SWT.
Damnhandy 
It's been 2 years, zeeshan. Where are those findings? >(
LikeLike
I’m a new java developer coming from an ms background, so I guess what I have to write here won’t come as a surprise to anyone. I’m becoming comfortable with both swing and swt, and evaluating them both as I go. I’m honestly amazed that there isn’t more support for swt, and a lot less for swing. I mean honestly – user experience is everything. How they feel about using your app defines how they feel about your company. Swing is ugly, and performs badly, and I just can’t get passed that. Nor will the end user. They won’t call you at your desk and say it to you, but what they’ll be thinking is “This doesn’t look right. In fact, this looks bad. What are those black sections when I expand my program window? Is there something wrong with my computer? This program is terrible. There must be something better then this…”. For myself, I work on swing apps when I have to. At the moment, all java development where I work is swing. As a result, when I tell one of the users there that I’m going to build a new app in java, they look at me like I just told them I was about to fart.
I guess I just don’t understand why anyone would DECIDE to be represented by a product that performs badly and is ugly by design, when you can choose better.
For myself, I’ll choose better every time I can.
LikeLike
I’m a new java developer coming from an ms background, so I guess what I have to write here won’t come as a surprise to anyone. I’m becoming comfortable with both swing and swt, and evaluating them both as I go. I’m honestly amazed that there isn’t more support for swt, and a lot less for swing. I mean honestly – user experience is everything. How they feel about using your app defines how they feel about your company. Swing is ugly, and performs badly, and I just can’t get passed that. Nor will the end user. They won’t call you at your desk and say it to you, but what they’ll be thinking is “This doesn’t look right. In fact, this looks bad. What are those black sections when I expand my program window? Is there something wrong with my computer? This program is terrible. There must be something better then this…”. For myself, I work on swing apps when I have to. At the moment, all java development where I work is swing. As a result, when I tell one of the users there that I’m going to build a new app in java, they look at me like I just told them I was about to fart.
I guess I just don’t understand why anyone would DECIDE to be represented by a product that performs badly and is ugly by design, when you can choose better.
For myself, I’ll choose better every time I can.
LikeLike
I am an experienced swing developer but never touched SWT. Now I a forced to use SWT since someone else in the company used it for a related GUI. I hope it would be good to learn SWT, but no idea what I am going into yet. I will post my findings.
LikeLike
I am an experienced swing developer but never touched SWT. Now I a forced to use SWT since someone else in the company used it for a related GUI. I hope it would be good to learn SWT, but no idea what I am going into yet. I will post my findings.
LikeLike
I am learining SWT on eclipse (current project), and i just hope it is better/same as
c++ with QT4!
So far i am not impressed as already SWT is missing a good Open source GUI designer/builder
LikeLike
I am learining SWT on eclipse (current project), and i just hope it is better/same as
c++ with QT4!
So far i am not impressed as already SWT is missing a good Open source GUI designer/builder
LikeLike
I do plenty of both JFC (Swing) and EclipseRCP/SWT. I’m more proficient in JFC, yet I’m finding that more projects are tending toward SWT. My first reason for SWT is their Tree component. It is much better than the JTree and JTreeTable in JFC. Almost all of my apps have a complex Tree view. While one shouldn’t center around a single component when choosing a UI framework, I will say it isn’t the only one.
Probably the more powerful reason is the SWT Browser component. It is essentially similar to the commercially available WebRenderer toolkit. RCPs need browser windows, and JFC just doesn’t have an out-of-the-box answer here. Mattise is compeling for JFC development, but the GroupLayout isn’t even a standard part of the JFC yet.
Personally, I prefer JFC APIs to SWT, but as I get better SWT I do find some aspects of their APIs to be well designed.
LikeLike
I do plenty of both JFC (Swing) and EclipseRCP/SWT. I’m more proficient in JFC, yet I’m finding that more projects are tending toward SWT. My first reason for SWT is their Tree component. It is much better than the JTree and JTreeTable in JFC. Almost all of my apps have a complex Tree view. While one shouldn’t center around a single component when choosing a UI framework, I will say it isn’t the only one.
Probably the more powerful reason is the SWT Browser component. It is essentially similar to the commercially available WebRenderer toolkit. RCPs need browser windows, and JFC just doesn’t have an out-of-the-box answer here. Mattise is compeling for JFC development, but the GroupLayout isn’t even a standard part of the JFC yet.
Personally, I prefer JFC APIs to SWT, but as I get better SWT I do find some aspects of their APIs to be well designed.
LikeLike
>Anytime you have an acrhitecture shift like Apple has, SWT will ALWAYS lag behind.
>that is my point.
But you are making my point. Does the fact that SWT is not owned by Sun (or Apple) and is not shipped with the operating system or the JDK have any bearing on the quality of the library? In fact, SWT is ahead on Vista. It already looks and feels right.
Zoft
LikeLike
>Anytime you have an acrhitecture shift like Apple has, SWT will ALWAYS lag behind.
>that is my point.
But you are making my point. Does the fact that SWT is not owned by Sun (or Apple) and is not shipped with the operating system or the JDK have any bearing on the quality of the library? In fact, SWT is ahead on Vista. It already looks and feels right.
Zoft
LikeLike
IMHO RCP is the future of java GUI development. RCP is not just fancy windows and buttons, it offers a framework that makes you focusing on the business case development. So it saves you a lot of time and pain that you’d normally have with swing. Think of the pain to implement drag and drop between different components. Use RCP and you don’t need to care about this stuff. I love it!
LikeLike
IMHO RCP is the future of java GUI development. RCP is not just fancy windows and buttons, it offers a framework that makes you focusing on the business case development. So it saves you a lot of time and pain that you’d normally have with swing. Think of the pain to implement drag and drop between different components. Use RCP and you don’t need to care about this stuff. I love it!
LikeLike
I think you’re spot on here, Ryan, and this is the exact problem I have always had with SWT, independent of my employer (which changed during development by the way). As Shai says, I too suspect it would never have seen daylight is Swing had got better sooner – it would just have stayed in the labs at OTI.
The entire success of the Java platform has come from it being that, a platform, where an entire set of technologies is always delivered intact so that the developer can rely on them being present and compatible. The Java platform succeeded because every platform provider was required to ship at least the full platform; that way, each time there was a development or change in the underlying system, the platform provider was required to allow for it and we weren’t all waiting for some unaccountable third party to deliver parts of it.
SWT breaks that model. Together with JFace and especially GEF it encourages dependence on a non-mandatory third-party-supplied subsystem that replaces a fundamental subsystem of the Java platform. It is certain to break on all OSes sometimes and on some OS, eventually, for all time when no-one can be bothered to re-implement it. Regardless of its technical merits (and, for the Windows programmer, it certainly has some), the fact it will never be guaranteed to be available on every Java instance rules it out as a technology in my view – high time it was taken to the JCP.
LikeLike
I think you’re spot on here, Ryan, and this is the exact problem I have always had with SWT, independent of my employer (which changed during development by the way). As Shai says, I too suspect it would never have seen daylight is Swing had got better sooner – it would just have stayed in the labs at OTI.
The entire success of the Java platform has come from it being that, a platform, where an entire set of technologies is always delivered intact so that the developer can rely on them being present and compatible. The Java platform succeeded because every platform provider was required to ship at least the full platform; that way, each time there was a development or change in the underlying system, the platform provider was required to allow for it and we weren’t all waiting for some unaccountable third party to deliver parts of it.
SWT breaks that model. Together with JFace and especially GEF it encourages dependence on a non-mandatory third-party-supplied subsystem that replaces a fundamental subsystem of the Java platform. It is certain to break on all OSes sometimes and on some OS, eventually, for all time when no-one can be bothered to re-implement it. Regardless of its technical merits (and, for the Windows programmer, it certainly has some), the fact it will never be guaranteed to be available on every Java instance rules it out as a technology in my view – high time it was taken to the JCP.
LikeLike
That’s not the point I’m making Zoft, and if you actually read the post yo might have been able to make a valid counter point. The fact that SWT doesn’t run native on OS X Intel yet even though it is mostly Java is my point. Anytime you have an acrhitecture shift like Apple has, SWT will ALWAYS lag behind. That is my point.
LikeLike
That’s not the point I’m making Zoft, and if you actually read the post yo might have been able to make a valid counter point. The fact that SWT doesn’t run native on OS X Intel yet even though it is mostly Java is my point. Anytime you have an acrhitecture shift like Apple has, SWT will ALWAYS lag behind. That is my point.
LikeLike
These arguments aren’t valid at all. They all come down to, “SWT is not Swing”, meaning that it doesn’t come bundled with the JDK or the Mac OS. There is also a bunch of speculation about Vista. My money is on SWT to look and feel right on Vista (native widgets) versus Swing (an emulation)
Zoft
LikeLike
These arguments aren’t valid at all. They all come down to, “SWT is not Swing”, meaning that it doesn’t come bundled with the JDK or the Mac OS. There is also a bunch of speculation about Vista. My money is on SWT to look and feel right on Vista (native widgets) versus Swing (an emulation)
Zoft
LikeLike
There is more in SWT than a bunch of widgets: J/Face.
You will quickly find the Swing MVC and threading models painful compared to SWT+J/Face.
LikeLike
There is more in SWT than a bunch of widgets: J/Face.
You will quickly find the Swing MVC and threading models painful compared to SWT+J/Face.
LikeLike
SWT started development when Swing was brand new and very bad. By the time SWT entered beta Swing improved but didn’t match its potential (JDK 1.3 era). According to friends at IBM SWT would not come into being if Swing was at the JDK 1.3 level back when SWT development started.
Today with Swing showing the massive improvements the choice of using SWT is slowley becoming obsolete and the main people to use it are:
1. People building highly platform specific code.
2. Open source developers who want a full “free” stack.
3. RCP developers who want the Eclipse look and feel.
4. Eclipse plugin developers.
5. The debate between lightweight/heavyweight components is a very old one (it existed in Smalltalk toolkits) some people picked sides 20 years ago and will never shift sides.
Most new projects use Swing and most existing projects are based on Swing, it is more mature and simpler to use/extend.
LikeLike
SWT started development when Swing was brand new and very bad. By the time SWT entered beta Swing improved but didn’t match its potential (JDK 1.3 era). According to friends at IBM SWT would not come into being if Swing was at the JDK 1.3 level back when SWT development started.
Today with Swing showing the massive improvements the choice of using SWT is slowley becoming obsolete and the main people to use it are:
1. People building highly platform specific code.
2. Open source developers who want a full “free” stack.
3. RCP developers who want the Eclipse look and feel.
4. Eclipse plugin developers.
5. The debate between lightweight/heavyweight components is a very old one (it existed in Smalltalk toolkits) some people picked sides 20 years ago and will never shift sides.
Most new projects use Swing and most existing projects are based on Swing, it is more mature and simpler to use/extend.
LikeLike
Very valid arguments. If portability is a concern (even a minor one), and is more important than speed or look & feel, the primary reason why SWT is prefered, then by all means, go Swing. But this doesn’t mean that the programmer should abandon Java just because the he/she wants to program in Windows. There are various reasons why Java is still desirable – e.g. familiarity with the language, possibility of the UI being both rich client and thin client (backend already in Java so…), etc. I’m sure others can think of various other possibilities.
However, you also hit a point when you implied that some people try to do Java with everything. “Use the right tools” should be a more proper mindset. If a software needs only run on Windows, with no exisiting Java code, then by all means – do Windows programming (.Net, MFC, whatever).
But I still say, keep SWT around. People need choices. I’ll be damned if one day I’m forced to go into either Swing or SWT.
LikeLike
Very valid arguments. If portability is a concern (even a minor one), and is more important than speed or look & feel, the primary reason why SWT is prefered, then by all means, go Swing. But this doesn’t mean that the programmer should abandon Java just because the he/she wants to program in Windows. There are various reasons why Java is still desirable – e.g. familiarity with the language, possibility of the UI being both rich client and thin client (backend already in Java so…), etc. I’m sure others can think of various other possibilities.
However, you also hit a point when you implied that some people try to do Java with everything. “Use the right tools” should be a more proper mindset. If a software needs only run on Windows, with no exisiting Java code, then by all means – do Windows programming (.Net, MFC, whatever).
But I still say, keep SWT around. People need choices. I’ll be damned if one day I’m forced to go into either Swing or SWT.
LikeLike
Pingback: Todd Ditchendorf’s Blog » Blog Archive » Why Bother with SWT?