SWT, Swing, or AWT - Which Is Right For You?

An anonymous reader writes "Why is there more than one Java GUI tool kit? The best answer is that one size does not fit all, nor is there a one-size-fits-all GUI tool kit to be invented soon. Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience. Read descriptions of each tool kit's basic features, and the pros and cons of using each."

Comments

Huh?

[Yaztromo]

Why is there more than one Java GUI tool kit? The best answer is that one size does not fit all

That hardly answers the original question -- it's true, but it doesn't answer the statement in question. That would be like saying:

Why is the sky blue? The best answer is that 1 + 1 = 2

The reason why there are three toolkits is simply: originally, Sun developed AWT. AWT was introduced with Java 1.0 as a way to obsfucate the drawing of common GUI widgets on a variety of platforms, using the native widget set. Unfortunately, this was problematic for many platforms, and wasn't very flexible.

Thus, Sun developed Swing. It supported more widgets, and did a lot of its own drawing in order to appear and generally layout the same across different platforms.

Swing, unfortunately, has some design limitations, not the least of which is that it is very memory hungry. When IBM decided to "port" VisualAge for Java from being a Smalltalk-based product over to using Java, they found that Swing wasn't up to the task, so they decided to develop their own widget toolkit, called SWT. SWT wasn't exactly intended for use outside Eclipse, mind you -- it's just that many developers decided to use it as such.

So we're left with a bit of a GUI mess on our hands in the Java world -- one I really wish would be fixed. Swing works, but it can be slow and memory intensive. SWT is non-standard, and requires a platform-specific module which users may not already have installed (which means either you have to tell them to download and install it, or you have to create a bunch of installers for different platforms to allow them to run your SWT-based application).

That is why we have thre different toolkits. For all intents and purposes, the bulk of AWT is deprecated and shouldn't be used for its widgets. It is simply difficult to get rid of due to the number of legacy applications out there which are still using it, and which will probably never be updated to use Swing.

And then there is Cocoa-Java...

Yaz.

Re:Huh?

[Yaztromo]

I don't think it is fair to use the swing memory argument anymore. It is really something that has been worked on.

I agree that there have been improvements, but I'm sorry -- I do think it's fair to continue to take Sun to task for this still.

A quick example -- the jSyncManager, my most popular OSS application. It can be run in either GUI or console mode. In both, the engine code is identical -- only the user interface differs. Firing it up in GUI mode uses about 35MB of RAM on my Mac OS X 10.4.5 based PowerBook. Firing it up in console mode uses ~15MB of memory.

That's a 20MB difference, and that is just after start-up. The GUI has a single window, with three menus, and a total of 11 menu items. There are NO widgets in the window -- instead it just has a graphic (it's meant to be run minimized -- the menus allow access to help, configuration items, and the log window). And yet that uses 20MB.

Activating every menu item that bring up a GUI dialog once, with the exception of the Help subsystem (which uses JavaHelp) brings it up to ~45MB of memory usage. Bringing up everything including JavaHelp once causes it to use ~55MB of memory. That is 40MB of GUI, and it is all absolutely trivial stuff -- excluding JavaHelp, it's probably less than 50 widgets all together.

True -- I have 1.25GB of RAM in my system, so 40MB is barely even noticed. Still, this is an absolutely trivial GUI (the complexity is in the data synchronization engine -- again, this application is meant to be a "fire-and-forget", run it in the background program which handles PalmOS data synchronization, and doesn't typically require any user input other than configuration).

For a more complex comparison, I fired up "Tapear", a clinical document management system that is part of another Open Source project I work on known as OpenTAPAS. It has only one window, but has hundreds of widgets of all types in it, with multiple tabs for a whole variety of different view types. It doesn't have much of anything in terms of an "engine", as it retreives all of its data from a remote database. After loading it up and opening up a single patient, it uses 80MB of RAM -- more than even my entire IDE (Xcode) uses by 25MB.

(I should note that all the above tests were done with the latest release version of Java 1.5 for Mac OS X (PPC)).

One more example -- Limewire 4.9 uses ~75MB of RAM with no transfers.

Sorry, but Swing is still quite memory hungry. Can you imagine running all of your applications as Java applications? Improvements are being made, but I think there is room for further improvements in this regard.

Yaz.

As this is a typical Slashdot wankathon story....

[tonywestonuk]

.... let me post two opposing sides of the swing vs swt debate:

Swt is crap

and

Swing is crap

Advantages and disadvantages?

[kwerle]

Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience.

Having used them, I'm pretty sure that each just has a different set of disadvantages.

Spoiled after 15+ years of [NeXT|Open|GNU]Step/Cocoa, I guess.