SWT versus Swing/awt

[Tad Dicks]

I've never used swt but I've read a little bit about how it "remedies" many of the issues users have with java gui interfaces (main one being too slow).

I also know that eclipse uses swt. Is it possible to build applications using SWT in other ides (can't imagine why it wouldn't be but I've not heard of it)?

Is SWT completely portable? or is it tied to the OS? I thought I heard/read that it relies more on the OS than swing.

I have a limited amount of experience with swing (most of the java I've written has been servlet/jsp based or command line) and none with SWT. The next project I'm working on is a Desktop application with a fairly complex GUI (the proto-type was written by someoene else in VB) several tabbed panes, a navigation tree (or two), along with various other buttons text fields etc.

Is it worth my time to learn swt? is there a different toolset I should look at? (jsf?)

I'm just trying to gather some information/opinions at this point. Any comments are apreciated.

-Tad

[Gregg Bolinger]

Moving to the Swing/SWT forum so that this soon to be flame war can at least be in the right forum...

[Gregg Bolinger]

I've never used swt but I've read a little bit about how it "remedies" many of the issues users have with java gui interfaces (main one being too slow).

Swing being slow is a common misconception. Slowness in swing apps is due to bad programming. The API is not the cause. See this for a very good presentation on Swing Threading. As far as "many of the issues" you would have to be specific. I don't know of any issues with Swing that SWT remedies.

I also know that eclipse uses swt. Is it possible to build applications using SWT in other ides (can't imagine why it wouldn't be but I've not heard of it)?

You can build any kind of app you want with SWT. You just need the JAR's and the native libraries

Is SWT completely portable? or is it tied to the OS? I thought I heard/read that it relies more on the OS than swing.

SWT has some native libraries the each supported platform. So it is portable in the sense that as long as you have the shared libraries for the targeted platform, SWT will run just fine. However, there are things you can do in SWT that will tie it down to an OS. For example, you can open Excel inside an SWT app. This funcationallity would of course tie you down to using Windows.

I have a limited amount of experience with swing (most of the java I've written has been servlet/jsp based or command line) and none with SWT. The next project I'm working on is a Desktop application with a fairly complex GUI (the proto-type was written by someoene else in VB) several tabbed panes, a navigation tree (or two), along with various other buttons text fields etc.

Is it worth my time to learn swt? is there a different toolset I should look at? (jsf?)

I'm just trying to gather some information/opinions at this point. Any comments are apreciated.

JSF is web based. So you probably won't want to look into that unless you want the new app to be a web app. As far as what you should look into, in my opinion there are 2 factors that you should consider when deciding between SWT and Swing.

1. Does the app require native look and feel. SWT looks like the targeted platforms native GUI. Swing apps look like Swing apps, not the native OS.

2. Do you need to be able to customize components? Swing has a huge advantage over SWT when it comes to customizing components. YOu can do it in SWT but it's quite limited and quite difficult. It is relativly easy to extends a Swing component to make it do what you want or better yet, create an all new component all together.

There are a ton of discussions similar to this in this very forum if you do a search. Also, this is a common blog topic so Google will turn up a lot of information for you as well.

[Tad Dicks]

Thanks for the info, I'm not sure how I missed this forum (or else I would have posted in here initially).

As to "issues" with swing, the ones I've come across personally (ok maybe its not swing, maybe it was bad code etc): I've worked with some truly slow java apps (especially the first time a command is executed). I've had some truly annoying problems with NetBeans hanging for minutes.

All that being said I think I'm leaning towards using swing.

So it is portable in the sense that as long as you have the shared libraries for the targeted platform, SWT will run just fine.

Are the shared libraries something you would include with each application (the particular library for the particular platform your deploying on?).
Or would you bundle each library inside of the application (putting each library that you would want your application to run on inside the jar)?

again thanks for the information,

-Tad

[Gregg Bolinger]

As to "issues" with swing, the ones I've come across personally (ok maybe its not swing, maybe it was bad code etc): I've worked with some truly slow java apps (especially the first time a command is executed). I've had some truly annoying problems with NetBeans hanging for minutes.

Netbeans is horrible. I think Sun should be embarrased by it. And the worst thing is a lot of people base their opinion of Swing on Netbeans.

Are the shared libraries something you would include with each application (the particular library for the particular platform your deploying on?).
Or would you bundle each library inside of the application (putting each library that you would want your application to run on inside the jar)?

Kind of depends on how you are deploying and if you are using an installer for your app. I think there are only 1 or 2 shared libraries needed for each platform (I haven't messed with SWT lately so can't remember). They just need to be accessible however each platform makes this possible.

If deploying using Java WebStart, you would need to jar them up as a seperate jar from your app and sign them and then specify them in the JNLP file.

[Don Kiddick]

netbeans is much better these days, you still get some pauses but no worse than eclipse. They're both very large and complicated bits of software.

[Gregg Bolinger]

Originally posted by Don Kiddick:
netbeans is much better these days, you still get some pauses but no worse than eclipse. They're both very large and complicated bits of software.

I disagree. I messed around with Netbeans 4.0 last week and last night I started messing around with Eclipse 3.0.1. Both on the same PC and Netbeans is just crap. Even on my P4 3.4 with 1 GIG of RAM.

But this is not an IDE discussion, so let's get back on track.

[K Riaz]

Originally posted by Gregg Bolinger:

Swing being slow is a common misconception. Slowness in swing apps is due to bad programming.

I keep hearing that sentence and it leaves me frustrated everytime. Why is it that, if you run Swing source code written by authors of various books, they do not "optimize" the code to make it "look" fast? How can such popular authors who have years of experience in writing programs also produce such bad software? Why is JEdit, Netbeans and OpenOffice so poor? These are written by software companies as commercial software. But these are still slow - how can every vendor be writing "poor" code? To me, it seems that you must be an expert and an experienced Swing programmer to be able to "write good code" so it can run fast. Only then can you write compariable native applications. But I am yet to see a commercial application written in Swing which is fast - prehaps because even writers themselves realise that no matter how well the code is written, they cannot get it to "look" fast to the end-user. That is why developers keep churning out slow Swing applications and end-users continue to say "Swing is slow". I bet the developers are thinking: "Hey end-user, we tried really hard to make it run fast and our team of professional developers did everything, sorry it still looks slow though".

For me, Swing just doesn't cut it. First user preceptions of Swing is "its slow and ugly looking" and rightly so. You need to have a good argument to change their opinions - you cannot change first impressions can you? Why should you as a programmer need to write so much code to do the most basic of things to make it run faster? You can write a very good looking application in SWT with very basic knowledge of the controls, and it runs as quickly as a native application. That is why SWT is much better than Swing because it does not require you do have a Ph.D in multithreading and GUI issues. End-users judge software on how its GUI looks and how well it runs, and Swing applications always leave me with a horrible feeling afterwards. You need to write more code in Swing than in SWT to do the same thing if you want to make Swing really fast (supposedly). Ask yourself why Eclipse is so popular - if it was written in Swing, I doubt many people would use it. Look at the forums on javalobby.org under the "Swing is slow" discussion, professional developers echo this opinion. Look at NetBeans, its slow and ugly. If the software company (with supposedly professional developers) who made NetBeans cannot write good code to make it run faster, what hope is there for the rest of us? How can you encourage new Java Developers to learn Swing when the biggest vendors producing Swing software cannot make it run any better?

IBM have really embarassed Sun with SWT. So what if it uses native libraries and needs a different .dll for each platform? (if thats a problem, write a good installer with all the libraries for the major platforms). Its a very very very small price to pay compared to what you get back (how hard is it to copy half a megabyte dll to the Window dir?): a nice and fast GUI which is easy to code and understand, with the knowledge that the code is still cross-platform and that a popular IDE (Eclipse) has been successful because of it, having won Java fans from across the globe.

Good enough for me.
[ February 13, 2005: Message edited by: Kashif Riaz ]

[Gregg Bolinger]

Frankly I don't know why "professional developers" write poor Swing code. The only thing I have to say is IntelliJ's IDEA is 100% Swing and runs faster and better than Eclipse. This is also echoed throughout the community. People run eclipse because it's a decent IDE and is free. Not because it's faster than the other one's out there. Developers don't look at Eclipse and say "hey, this is written in SWT, it must be better and faster." The fact that Eclipse is written in SWT is an astirisk at the bottom of the feature list. Unless IBM wrote the feature list .

I kow a ton of Swing apps that run really well. Just look at the Swing Sightings list where there are hundreds of professional Swing applications. Some run poorly, but a lot of them run really well. Yes, I try a lot of them out. Show me a similar list of hundreds of SWT apps. And don't give me that SWT hasn't been around long enough. People just aren't developing SWT outside of Eclipse plugins or at least aren't advertising the fact that they do.

Look, I don't have a problem with SWT. And if an end user required a native look and feel, I'd use it. But this SWT is faster than Swing debate is tired and unprovable. SWT is easier to code the basics elements because there isn't much you can do with SWT beyond the basic elements. Swing is just as easy for simple things. It becomes difficult when you need the out of the ordinary done. SWT was developed to make the Eclipse platform.
[ February 13, 2005: Message edited by: Gregg Bolinger ]

[K Riaz]

Originally posted by Gregg Bolinger:
Frankly I don't know why "professional developers" write poor Swing code.

They write poor code because the Swing community encourages it. Open any book on Swing and you'll be hard pressed to find an "optimize your Swing Java code" chapter. Look at the Swing tutorial on the Sun website - nothing there about speeding your Swing code.

The Swing model is a poor one for letting programmers write such code and they are getting punished bfor following experts who write books and training programmes using the very same methods, only to realise that its a disaster for end-users in the real-world. This is a mistake on Sun's side, because if thats how "well-versed" developers write it, why not everybody else? But Sun Microsystems aren't stupid, they know that if they introduce sections on optimizing Swing for newbies, it will scare those new-comers off Swing and probably Java. Your average GUI Developer should only need to worry about 2 things: The layout of GUI components and Event handlers. SWT achieves this. Anything extra and you are skating on thin ice and risking critism. This is what has happened to Swing - you need to do more work and Sun know this is not ideal at all, so authors et al don't mention it in their 1000 page Swing books and concentrate on Swing controls and Event Handlers.

[Gregg Bolinger]

Making sure your intense tasks get done in a seperate thread from the Swing thread is not difficult and it is the only thing you need to worry about to make Swing apps perform well. It's not a secret.

The reason books are written the way they are is because they all focus on the "newbie" programmer. And all those books on Swing don't require you to write any tasks that force you to use a seperate thread. So that's why it is not mentioned in the books. There are however a lot on online tutorials and resources that mention this, including Sun's own tutorials on Swing.
[ February 13, 2005: Message edited by: Gregg Bolinger ]

[Martina Renworth]

Swing is a fine GUI framework. I love working with it. However, the Windows LAF is not quite good enough. The standard Swing file open/save dialogs are atrocious. Even my mum thinks they look weird. Sun managed to screw up the system font in 5.0 :roll: so that it looks even uglier than before.
At least JGoodies corrects most of these issues.

The most popular SWT app around is probably Azureus, the bitorrent client. I doubt the average user knows it is a Java app, it is so snappy. I cannot believe a Swing equivalent would be anywhere near as responsive. But I'm willing to be proved otherwise.

[Steven Bell]

I've found no problems with Swing responsiveness or performance in anything I have written. One thing I really like about Swing is it's flexability. I was able to slap together a JTable that used a JTree as it's first column, with dynamic row adding ect., in a day and had it pretty well cleaned up and polished in two maybe three days. Very snappy and responsive.

With that said I would probably be singing a different tune without several peices of software:
JGoodies Forms
JGoodies looks
foxtrot
andSwing worker

This stuff makes building Swing apps so simple. Any time I write a listener I usually use foxtrot to do the action because it takes almost no effort to use. In the rare case that foxtrot just isn't the right way to go Swing worker steps in.

Take a look at these two:
Professional Swing: Creating polished apps
and Professional Swing: Threading

They cover the use of some of the utils I just listed.
[ February 14, 2005: Message edited by: Steven Bell ]

[Martina Renworth]

Yes using Foxtrot in the listener is an excellent idea. I think a lot of the perceived performance problems in Swing are due to too much activity in the event listeners, which holds up the AWT thread. Even a few innocuous looking lines can create many objects behind the scenes, best to run them in their own thread.

The problem is that neither SwingWorker nor Foxtrot is part of J2SE. Not too many books discuss them either. Only smart Googlers and readers of the Java Tutorial find out about these things. :roll:

[Alex Kravets]

Well I tend to agree with Kashif.
Gregg, when you say:

Frankly I don't know why "professional developers" write poor Swing code. The only thing I have to say is IntelliJ's IDEA is 100% Swing and runs faster and better than Eclipse.

Do you know what IntelliJ had to do to make their application fast? They might say that it's 100% Swing, but there might have been some major plumbing work done to make it fast.
Couple of months ago this company: think map called me up about a potenital interview. I checked out their website and the Visual Thesaurus looked very nice. While talking with I guess CEO of the company (it's a small company) he told me that they had to rewrite BIG chunk of Swing implementation in order to make the application faster. And it is, very fast. But look, they took this approach in order to make the API for their framework fast and stable -- and they did. Now they can build upon this API to produce fast "Swing" application. But that was them and may be IntelliJ. So, is this the case where in order to make a fast Swing Application a programmer must rewrite portions of base API of underlying GUI mechanism in order to make clients say: "Oh, it's fast. It must not be Swing." I don't think so. If I have something that is given to me as a base, I expect it to work (Swing has been around for sometime now). I don't need to rewrite half of it or make significant workarounds just to make the damn thing faster.

Alex
[ February 15, 2005: Message edited by: Alex Kravets ]

[Don Kiddick]

Maybe they didn't write it very well?
In my department, we write real time trading apps with ticking prices for thousands of instruments. We use Swing and it performs very well.
Another trick that a lot of people miss is TableRenderers. You generally need to override validate, repaint, revalidate, etc... for performance reasons, but people often don't do this (see DefaultTableCellRenderer for details). Hence the myth that "JTables are slow"
D.