Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

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

Posted by Zonk from the choose-wisely dept.
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."
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:
  • I'm lovin' it!
    • Gtk# is better.
      • GTK# could be better but it isn't better until such time as it becomes as easy as or easier to design a form using GTK# on Win32 as it is to design one with Windows.Forms. That certainly implies writing wizards and plugins that integrate into DevStudio to provide equivalent support for the alternative widget set. Until that day arrives, NO ONE using .NET on Windows is going to pay the slightest bit of attention to it.
        • Well, forms design is one of those things that looks like a mountain from one side but a molehill from the other, the dividing line being knowing the toolkit well enough to handle all the details you need to get something working.

          From a learning perspective I'd say GTK# is simpler to learn, and Windows forms gets with wizards and painters gets you to something you can show a few hours faster. What really matters in the long run is maintenance. Good programmers are careful to sever relationships between bit
          • These are all good points but the reality is that GTK# won't have any mindshare or eyeballs while it is perceived rightly or wrongly to be hard to use than Windows.Forms. It takes a few minutes to produce a form in DevStudio, moves some buttons around, build and test it.

            GTK# has no integration at all with DevStudio so you must create a console based .NET app, start changing the references, write the code to initialise / terminate GTK#, fire up Glade, screw around with its just plain weird interface, pop b

    • My NIB files are laughing at you.
    • Windows.Forms at least for 1.1 is pretty wretched. What makes it nice to use is the visual designer in .NET. Since it has no layout manager and the designer is so straightforward, it is easy enough to slap a form together. It's only when you start playing around with it in detail that you realise it is very much tied to the Win32 platform.

      I understand .NET 2.0 has layout managers but I haven't spent any time playing around with them yet. I know from experience of Java IDEs that it could hardly do a worse

      • Re:System.Windows.Forms (Score:2, Informative)

        by perkr ( 626584 )
        Try netbeans 5, they have Mantisse, a GUI builder that handles layout managers in a straight-forward way. I didn't really believe the hype about it first, but a friend of mine very new to Swing managed to build a non-trivial UI that scales very well upon resize using nothing but it.

  • Is none of the above an option? (Score:5, Insightful)

    by killjoe ( 766577 ) on Sunday February 26, 2006 @04:01AM (#14803101)
    You don't have to go with those, there are java bindings for everything!> QT, wxWindows, even curses!.

    Pick the one you like!

    • Re:Is none of the above an option? (Score:5, Funny)

      by penguin-collective ( 932038 ) on Sunday February 26, 2006 @04:25AM (#14803141)
      Yeah, trouble is, no matter which you pick, you'll still be programming from Java.

    • Re:Is none of the above an option? (Score:4, Informative)

      by ultranova ( 717540 ) on Sunday February 26, 2006 @04:26AM (#14803144)

      You don't have to go with those, there are java bindings for everything!> QT, wxWindows, even curses!.

      Pick the one you like!

      Pick something besides AWT/Swing, and your users need to download and install it. That lessens the chances that they pick your program, or that they will even be able to pick it - after all, every third-party library needed decreases the chances that all of them have been ported to the target platform.

      • They need to download a JRE anyway so what's the big deal.
        • Which is why web developers tend to now avoid java and use activeX instead.

          I have seen mac web developers standardize on WMV instead of quicktime even though they can't view them on thier own system! Why? Because the user will go to a different site rather than download quicktime.

          IE is the standard and java is not included so its best not to use and stick with Microsoft based standards.

          And you wonder how MS is able to retain its monopoly?

      • Pick something besides AWT/Swing, and your users need to download and install it. That lessens the chances that they pick your program, or that they will even be able to pick it - after all, every third-party library needed decreases the chances that all of them have been ported to the target platform.

        Bundle the necessary libraries with your app, and don't use libraries that require a separate download. It's all about the licensing.

        (tig)
  • The fastest and most furious (and most widely jvm comatible) are thin awt + a few thin third part libraries for complex widgets. Swing is to FAT for my taste!

  • Why is AWT even an option? (Score:3, Insightful)

    by dood ( 11062 ) on Sunday February 26, 2006 @04:18AM (#14803125)
    It should be SWT vs Swing. There's hardly a reason to use the plain AWT when there's Swing (a much more powerful library built on top of AWT).

  • My six word summary (Score:3, Interesting)

    by MillionthMonkey ( 240664 ) on Sunday February 26, 2006 @04:27AM (#14803145)
    SWT : buy
    Swing: hold
    AWT : sell

  • Huh? (Score:5, Informative)

    by Yaztromo ( 655250 ) on Sunday February 26, 2006 @04:38AM (#14803174) Homepage Journal
    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.

    • Honest question - what do you mean by saying that SWT is 'nonstandard'?

      • Re:Huh? (Score:3, Informative)

        by Yaztromo ( 655250 )

        Honest question - what do you mean by saying that SWT is 'nonstandard'?

        It's not part of the Java standard from Sun. That isn't to say that SWT itself doesn't conform to its own defacto SWT standard -- it's just not part of the Java standard. It is my understanding that legally, IBM can't advertise SWT as being "Java", and can't even technically call Eclipse a Java IDE (even though it does the job just fine).

        Sun needs to take a look at what Apple has done with Interface Builder and Cocoa. It should th

    • I have never heard of anyone who did not use Swing because of its memory usage. Most people have a very simple problem with Swing: GUIs created with Swing are ugly and do not look professional. People use AWT because AWT apps look much better.

      • Re:Huh? (Score:3, Insightful)

        by Yaztromo ( 655250 )

        I have never heard of anyone who did not use Swing because of its memory usage.

        Are you new around here? ;)

        Admittedly, I use Swing. I don't avoid it because of its memory requirements, but they are a source of continued concern to me. Admittedly, the issue doesn't get as much attention these days as RAM continues to become ever more inexpensive, but there is still serious room for improvement. Read my other posting here on this subject [slashdot.org] for some examples.

        Swing is flexible, and can create some nice GUI

        • Actually I am not that new, that's why I am wondering. I didnt do any Java GUI development in the last few years, but I remember using Swing for medium-size apps in the late 90s, on computers with 128 MB RAM. RAM was never an issue.
          The L&F was a huge issue though, so bad that we considered using Microsoft's (Windows-only) Java GUI and I eventually created my own toolkit on top of AWT.
    • Swing, unfortunately, has some design limitations, not the least of which is that it is very memory hungry.

      I'm surprised that you didn't mention the biggest problem with Swing for practical purposes, which is that the API was designed by an insane crack weasel with a terminal case of brain rot. Really, what sort of person thinks that getSystemLookAndFeelClassName is a sensible name for a function in a standard library? (There's certainly far worse issues, but that one always struck me as the most gratuitous

    • Re:Huh? (Score:2)

      by Malc ( 1751 )
      I would argue that Swing doesn't work. One of the big problems that Java has always had is that although it tries hard, it always fails to look and feel like a native app. It's frustrating for end users, who often decide you've written a second-rate app because it doesn't feel right.
    • Swing is a bloated nightmare of an API, way overly complex for what it tries to do. It gives you great flexibility, but things that should be simple—like setting a fixed width (of the right width) for a JTree—are actually difficult programming tasks. Heck, everything is time-consuming. If you work long enough on your GUI, Swing does give you the power to do a lot. But it isn't trivial to use, unlike AWT.

      When Swing was introduced as an add-on package (for Java 1.1) the size/memory was a big deal,

  • Right for *YOU*? (Score:2, Insightful)

    by devjj ( 956776 )
    Shouldn't the question be "Which is right for your project?"

  • As this is a typical Slashdot wankathon story.... (Score:5, Informative)

    by tonywestonuk ( 261622 ) on Sunday February 26, 2006 @04:43AM (#14803183)
    .... let me post two opposing sides of the swing vs swt debate:

    Swt is crap [hacknot.info]

    and

    Swing is crap [ahmadsoft.org]
    • What a pile of FUD. Like says that a myth that SWT is faster then Swing, but when you read it you find he hasn't proven it at all.

      I use SWT from day to day. Absolutly no problem. The only thing I might agree with the article is that SWT can be hard to learn. However just get swt designer http://www.swt-designer.com/ [swt-designer.com] . Even an idiot could design GUI from that. But hey designing good GUI is hard regardless of the API used.
      • I don't have much experience with SWT, but I do occasionally use one app that uses it; Azureus. I don't know what this looks like on other platforms, but on the Mac it's hideous. No live resizing (outline only), controls not automatically fitting the size of the window (when it starts, you often have to resize it a little bit to force a redraw, and then things line up). Oh, and it manages to leak both memory and CPU[1].

        I don't know how many of these are SWT problems, and how many are just incompetence o

  • Advantages and disadvantages? (Score:5, Funny)

    by kwerle ( 39371 ) <kurt@CircleW.org> on Sunday February 26, 2006 @04:49AM (#14803191) Homepage Journal
    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.

  • None of the above. (Score:5, Interesting)

    by seebs ( 15766 ) on Sunday February 26, 2006 @04:54AM (#14803200) Homepage
    Buoy [sourceforge.net] is your friend. It's built on top of Swing, but it's actually sanely usable. I recommend it on the grounds that it is the only Java GUI toolkit I have ever used that did not leave me longing for the sweet embrace of death. Developing an application using Buoy is substantially less painful then stabbing yourself in the eye with a fork. In the world of Java GUI development, this is high praise indeed.

    Seriously, though. If you are doing GUI work in Java, but your actual goal is to get something else done, and you would like the GUI toolkit to take less than 80% of your development effort, use Buoy. It's not "dumbed down"; it's just SANE.
    • I do not know, but a framework which does not even obey the standard Java naming conventions (just look at the package names) looks rather suspicious. Oh, and can we please stop this silly idea of prefixing class names with some letter? Sun cannot fix that in Swing because they need to keep it backwards-compatible, but no such new monstrosities should ever be created.

  • Swing (Score:4, Interesting)

    by Anonymous Coward on Sunday February 26, 2006 @05:09AM (#14803223)
    I've never used SWT, but I have quite extensive experience in both AWT and Swing, as well as many other GUI toolkits, including two cross platform toolkits of my own for a commercial product that shall be anonymous in this post.

    In my opinion the Cocoa AppKit on OS X is perhaps the most elegant overall. The problem is that with Cocoa AppKit, the common things are extremely simple and easy to do, but the more uncommon things can be quite tricky. With Swing, the most common things are still simple, but take considerably more code than with Cocoa. But when you get to something more advanced where you want to get some custom behavior (maybe dealing with drag & drop on some custom widget, or perhaps you want to customize the selection model on a tree widget or somethign similar), then Swing suddenly becomes much easier to work with compared to the otherwise simple Cocoa.

    AWT isn't really an option over Swing in my opinion. It's there for historical reasons, and as the low-level API for Swing. Swing is built on top of AWT, after all.

    There are a couple of larger problems with Swing:

    1) Performance can suck if you don't know exactly what you're doing.
    2) Making it behave exactly like you want often requires you to know it quite well.
    3) It is quite large and complex, and can seem overwhelming to learn.

    The performance problem is actually the biggest reason Java is still perceived as being slow by many people who aren't familiar with it. Developers often shoot themselves in the foot with threading issues, and it makes Swing UI's seem slow and poorly responsive. Also, because of poor understanding of the more advanced layout managers, it's also not uncommon to see Swing based UI's that just... look sort-of wrong. They don't look like native apps. Not because of look & feel issues of the widgets, but because of margins and paddings around widgets being wrong. You have problems like buttons being too large, text areas being right up to the edge of the window, quick-hack looking layout of widgets in preferences-style windows that have a large number of widgets, and so on. You often also see things like the app not painting itself during window resize drags, default window icons, inconsistent font sizes, and so on. Many of these are simply caused by people not fully knowing the Swing API and not knowing how to do things properly. It's not that you can't do them right, it's that people don't know the tool thoroughly. In my opinion, this is directly caused by the API being overwhelmingly large for many developers. While it gives Swing its incredible flexibility, it also indirectly is the cause for many of its problems.

    Sun is tackling the performance problem from one end. They are working on accelerating a lot of the lower level graphics API (image drawing, primitive drawing, etc.) with OpenGL and DirectX. This helps a lot in many situations, but it doesn't help in the cases where people do 3 second tasks in a UI event callback method. Likewise, the ugly-UI problem is being helped by better IDE's (Matisse in Netbeans 5, for example) and by Java SE 6's (Mustang) better handling of system look and feels.

    Still, there's a long way to go. But Swing is getting better every day, and it's the standard choice that works on all platforms, and it IS possible to do excellent UI's with it even today. You just need to learn it well. My recommendation is to read the API reference until you know it by heart. Then study the Swing source code to see how things work under the hood.
    • MOD PARENT UP.

      In summary, the reason that there are SWT, Swing, and AWT is that Java is an unfinished language?

      My understanding is that Java is unfinished because Sun is holding it too tightly and yet has not provided sufficient support for finishing the language.
      • I agree, the changes in 1.5 with lists and foreach prove 1.4 was not finished. I still like the language, stuff that doesnt use hardware too much is very portable, moreso than .net. Operator Overloading would be a nice addition though. That aside it's quite good.

    • BTW, there is a third-party project providing a look and feel for Swing which fixes some of the bugs with Sun's implementation which would otherwise take forever to fix.

      It's called WinLAF [java.net].

    • Nice summary. Actually, SWT, Swing, and AWT aren't your only choices in Java, though. There are a lot of small toolkits out there that each have some fascinating features, such as using the 3D graphics accelerator, handling zooming or animation better, etc.

      The company I work for years ago branched one called "Jazz" (which has since been renamed Piccolo and mostly moved to C#: http://www.cs.umd.edu/hcil/jazz/ [umd.edu] ) and basically developed our own Java graphics toolkit. This let us make the things that are imp
    • Eep! Don't read the source code if you ever want to work on GNU Classpath or anything. Sun's licensing is a bit queer when it comes to the source code, so be careful if you want to remain "untainted"...

  • Swing is maturing, SWT has growing pains (Score:4, Interesting)

    by BortQ ( 468164 ) on Sunday February 26, 2006 @05:42AM (#14803276) Homepage Journal
    I give much credit to SWT for putting a fire under swing and forcing them to improve. The current Swing is much better then it was a few years ago. It can take some long years before a toolkit matures and best practices for its use come out. I feel like that is happening now with Swing. If some of the SwingLabs stuff gets put into the real pipe that would be lovely.

    SWT seems to be encountering some growing pains as it really starts to cover everything that a toolkit must. I wish them luck in pulling through even stronger (on all platforms please). SWT certainly has had a strong start.

    It seems like there are enough Java developers out there to support 2 GUI toolkits. I think in the long run this can only be good for Java as a whole. If people don't like one they can stick with Java and swap out the toolkit. If one eventually becomes "the one" then it will only be because the other pushed it to be the best it could.

  • JFC is a fine class library but it is horribly, horribly slow, and not even the latest versions pick up the native look & feel properly. Of course JFC is a nice API so that counts for it, as does the fact that installs by default, as do the abundance of tools. But SWT uses native widgets for its rendering so its considerably faster and more integrated with the environment. If both shipped in the same box, I'd pick SWT. As they're not, I'm reluctantly stuck with JFC.

    AWT is a waste of time. It's just t

  • I can't read the article but IMHO there is no clear winner in the SWT vs Swing debate (AWT died years ago).

    Swing is slower and not quite native, but comes with every Java VM (or the important ones anyway) and is very flexible.

    SWT is fast and more native, but requires external machine-specific JARs which can be a pain to deploy, and has a more limited design.

    In Java I tend to use Swing because I am making applets, so the deployment issues are important to me. If I was going to create a large-scale appli

  • Question (Score:5, Interesting)

    by Orlando ( 12257 ) on Sunday February 26, 2006 @07:34AM (#14803479) Homepage
    This may be a dumb question, but why can't Java just provide access to the existing desktop GUI (Windows, OSX, QT, whatever) rather than re-inventing the wheel with it's own set of widgets that inevitably don't look or behave like native apps?

    • Re:Question (Score:4, Informative)

      by LeninZhiv ( 464864 ) * on Sunday February 26, 2006 @08:24AM (#14803567)
      You can use Java with GTK, Cocoa, or native Windows toolkits. The question then becomes, why Java programmers are not interested.

      The basic reason for this is, your application's GUI becomes completely unportable, and you suddenly have little reason for having written it in Java in the first place instead of the platform's "standard" language (C, Objective C, or C#).

      A "middle way" is to do what SWT does and wrap the native widgets with a generic API. This creates a "lowest common denominator" problem, however, since you inevitably have to stick to only using those widgets which all your target platforms have...
      • Well, Qt and wxWidgets are as cross-platform as Java (Qt moreso; it has support for embedded devices and very low-end graphics environments like LCD panels), so I don't see the problem.

      • Re:Question (Score:3, Interesting)

        by archeopterix ( 594938 )

        A "middle way" is to do what SWT does and wrap the native widgets with a generic API. This creates a "lowest common denominator" problem, however, since you inevitably have to stick to only using those widgets which all your target platforms have...

        This "inevitably" is the consequence of forcing the full cross-platformness down the developer's throat. Yes, if you create One API and force the programmer to use it, the "lowest common denominator" problems are inevitable. But this isn't the only way. I use wx

    • This may be a dumb question, but why can't Java just provide access to the existing desktop GUI

      Because Java is supposed to work on Unix, and Unix doesn't have an existing desktop GUI. For many years, Motif was the standard, but those days are long gone. Now, Unix (and especially linux) are just a confusing mush of unstandardized toolkits that make no effort to maintain compatibility with anything (even themselves).

      To this day, if you want a standard toolkit on Linux, you may as well just write one yoursel

  • AJAX (Score:3, Insightful)

    by SoupIsGood Food ( 1179 ) on Sunday February 26, 2006 @07:38AM (#14803486)
    The correct answer is, "None of the Above."

    Before you invest a lot of time, effort and money crafting a GUI front-end for your application, you should really stop and consider that you may not need one.

    If your app is basically a way of querying a database on a server deep in the bowels of the computer room, you should be coding the interface as a web application. Especially now that AJAX is on the scene... modern AJAX tools and a Java backend can put together some very powerful applications that don't have the same development and deployment costs that an executable on every desktop would.

    AJAX isn't a cure-all, and not likely to help much if you're interacting with local datasets with lots of processing horsepower (as in an imaging program like the Gimp or a sound editing program) or constructing a platform-independant application that's mostly self-contained (like a game or a p2p client.)

    It is great for things like CRM applications, scheduling tools, inventory tools and ticket-monitoring... stuff that need to read and set values in a database somewhere. It's even good for applications that were previously in the domain of the workstation and the PC, like lightweight data visualization tools and PIMs.

    What's more, the development cycle of an application that only needs a copy of IE or Firefox to run will be a lot easier for you, the user/customer and the poor slobs in IT who would need to come up with a deployment plan, and =then= an upgrade plan when rev 1.2 comes out.

    SoupIsGood Food

    • Re:AJAX (Score:3, Insightful)

      by CrazyLegs ( 257161 )
      I'll agree with you to a point. What you're talking about is, really, the old fat vs thin client approach. Fat clients (a la Swing, SWT, whatever) makes loads of sense if:
      • you're in control of your clients/endpoints (i.e. sys mgmt not an issue)
      • you have skinny network connectivity
      • you have sophisticated and/or performance-sensitive GUI

      A thin client approach makes sense if:

      • you are NOT in control of your endpoints
      • you have adequate connectivity
      • you have simple GUI and linear dialogue flows
      • sub-second per
  • Swing has improved over the years, but it has improved at an unacceptable pace.

    Call me back when it finally supports Clear Type.

    Cheers,
    Adolfo
  • Today if you are not building it for the web you are just plain wrong. Now granted there are a few apps that will not fit the web model but no many.

  • A fourth option: SwingWT (Score:3, Informative)

    by caseih ( 160668 ) on Sunday February 26, 2006 @01:20PM (#14804329)
    As the article mentioned, Swing is a very good, advanced toolkit with some advantages over SWT. A project called SwingWT is an implementation of Swing using SWT, giving you a much faster GUI that looks and feels more native. So you can do all your development and initial testing with pure Swing, then swich the UI classes to SwingWT for a native look and feel on the hosts that support SWT. Seems like an interesting idea to me.

  • Too many freakin' guis (Score:3, Interesting)

    by borgheron ( 172546 ) on Sunday February 26, 2006 @01:58PM (#14804453) Homepage Journal
    This is the trouble with Java.. there are too many GUI libraries. Standardize on one and forget the rest. It seems that when an environment is born without one, it's destined to search for the perfect gui framework forever.

    As an example of an evironment which has never had this problem, take Mac OS X, it has had AppKit since the day it was created... and it will never see another major gui framework. Ah, yes... you can say but there's GTK and others available on the Mac, but they are not a threat to the *MAIN* AppKit framework... (they do, in fact use AppKit, so they aren't an outright replacement).

    Intersting dilemma...

    But... to get back on topic, I prefer SWT, it's faster, and it blends more readily with the native environment than the others.

    GJC

  • AWT is crap, Swing is heavy and slow, SWT is... (Score:3, Informative)

    by master_p ( 608214 ) on Monday February 27, 2006 @06:42AM (#14807204)
    AWT is totally crap; it lacks much functionality of modern GUIs.

    Swing is heavy; it implements its own window system, complete with event queues and region management. For those that don't know what regions are, they are display lists of visible rectangles. Clipping works by subtracting a region from another region, i.e. subtracting one list of rectangles from another list of rectangles. This means two things: a) crazy memory requirements, as each operation produces a new rect, b) slowness in order to compare all rectangles with each other.

    SWT seems the better option, but I have no idea, even after reading the article, if it is totally portable and extensible from Java.

Slashdot Top Deals

E = MC ** 2 +- 3db

Close