SWT, Swing, or AWT - Which Is Right For You? 323
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."
Google Cache (Score:2, Informative)
http://72.14.207.104/search?q=cache:Sdg9JPdYswMJ:w ww.ibm.com/developerworks/opensource/library/os-sw ingswt/+awt+swing+swt+features+opensource+site:www
Re:Google Cache (Score:2)
System.Windows.Forms (Score:2)
Re:System.Windows.Forms (Score:2)
Re:System.Windows.Forms (Score:2)
Re:System.Windows.Forms (Score:2)
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
Re:System.Windows.Forms (Score:2)
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
Re:System.Windows.Forms (Score:2)
Re:System.Windows.Forms (Score:2)
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)
Re:System.Windows.Forms (Score:2)
Re:System.Windows.Forms (Score:3, Informative)
Re:System.Windows.Forms (Score:2)
Re:System.Windows.Forms (Score:2)
That's great. Answering you're own question, I mean. I guess you don't need me.
Re:System.Windows.Forms (Score:3, Informative)
Re:System.Windows.Forms (Score:2)
I think you're giving .NET WebForms way too much credit.
Take a look at fundamental Java JFC and the contract interfaces it defines. Now take a look at web interface programming and JSF. I think you'll realize rather quickly that JSF is nothing more than a webcentric API for implementing the JFC contracts.
WebForms is the response to a little Apache project called "Struts". JSF builds on their concepts as well.
Add Java 5 annotations, stir, shake well, and deliver. It's a very nice 1.0.
Re:System.Windows.Forms (Score:2)
Fine just use gtk+? Well the users wont have it installed on their system. oops
I have not seen any programs that are cross platforms. Not even hello World programs that are written in c#. As far as I am concerned its proprietary
Re:System.Windows.Forms (Score:2)
WinForms was not submitted as a standard
SWT provides a wrapper around native Win32 APIs also, does that make it "patent-encumbered"? Now if you mentioned that some of the older
Re:System.Windows.Forms (Score:2)
So no specific patents but a penumbra of eminations from the top brass MS hints at things that may happen in mono ever becomes a threat to MS.
Right now it's just a
Re:System.Windows.Forms (Score:2)
Re:System.Windows.Forms (Score:2)
Funny how logic goes out of the window when a zealot looks at MS.
MS are going to defend their IP vigorously.
To sit back and let someone infringe your IP would not
Re:System.Windows.Forms (Score:2)
Re:System.Windows.Forms (Score:2)
Is there something about this task that prevents a programmer from abstracting it? I always follow the rule of three: the thrird time I do something it goes in a library.
Re:System.Windows.Forms (Score:3)
The reason no one does that is that all layouts are different, with different things that need to be resized or not, under different conditions. Like, if my window gets too small, this thing needs to be collapsed entirely. Or, as a window gets bigger, another thing only needs to be resized up to a point, then it is more useful to put the extra space somewhere else.
Is none of the above an option? (Score:5, Insightful)
Pick the one you like!
Re:Is none of the above an option? (Score:5, Funny)
Re:Is none of the above an option? (Score:4, Informative)
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.
Re:Is none of the above an option? (Score:2)
Re:Is none of the above an option? (Score:2)
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?
Re:Is none of the above an option? (Score:2)
Bundle the necessary libraries with your app, and don't use libraries that require a separate download. It's all about the licensing.
(tig)
Thin is IN (Score:2)
curses (Score:2)
Re:Thin is IN (Score:2)
Why is AWT even an option? (Score:3, Insightful)
Re:Why is AWT even an option? (Score:3, Interesting)
Re:Why is AWT even an option? (Score:2)
Re:Why is AWT even an option? (Score:2, Informative)
Perhaps you meant "raises the question".
http://en.wikipedia.org/wiki/Begging_the_question [wikipedia.org]
Surprising considering how often people get pulled up for this one on
Re:Why is AWT even an option? (Score:2)
Re:Why is AWT even an option? (Score:2)
Re:Why is AWT even an option? (Score:2)
I haven't tried SWT. It sounds like it takes some study to get started. Hopefully it is more compatible between Windows and X than AWT.
My six word summary (Score:3, Interesting)
Swing: hold
AWT : sell
Re:My six word summary (Score:2)
Huh? (Score:5, Informative)
That hardly answers the original question -- it's true, but it doesn't answer the statement in question. That would be like saying:
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? (Score:2)
Re:Huh? (Score:3, Informative)
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
Re:Huh? (Score:2)
Re:Huh? (Score:3, Insightful)
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
Re:Huh? (Score:2)
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.
Re:Huh? (Score:2)
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)
Re:Huh? (Score:2)
Swing is hard but effective (Score:2)
When Swing was introduced as an add-on package (for Java 1.1) the size/memory was a big deal,
Re:Huh? (Score:2)
You are, of course, quite correct. It has just been one of those days, I suppose :P.
Yaz.
Re:Huh? (Score:5, Informative)
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 [jsyncmanager.org], 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 [opentapas.org]. 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.
Re:Huh? (Score:2, Informative)
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.
I doubt that it really uses 20MB. It just appears to use 20MB. What's almost certainly really happening is that it's mapping 20MB more of virtual memory, of which very little is actually used. For example, if the program needs a cla
Re:Huh? (Score:3, Informative)
Re:Huh? (Score:4, Informative)
I'm quite aware of how to properly profile memory for Java applications, and yes, there is a 20MB difference in actively used memory. The virtual memory claimed is siginificantly higher than what I quoted -- where it's using ~35MB of real memory, the process is claiming a whopping 453MB of virtual memory (which of course isn't allocated at all, and thus doesn't really affect much of anything performance or RAM wise). Opening all four possible dialogs at once bumps that memory usage up to closer to 50MB.
I have a pile of Java memory profiling tools that all agree with this memory usage assessment. Now it's possible that the low level implementation on Mac OS X is more hungry than on some other platforms, but in my testing this is relatively equivalent to running it on Linux and Windows.
Sorry, but Swing is memory hungry. It tends to show in complex applications, which is one reason why I've kept the jSyncManager as simple as possible in terms of GUI.
Yaz.
Re:Huh? (Score:3, Informative)
I have asked my users, and they tend to be surprised at how fast the jSyncManager [jsyncmanager.org] is. At one time it was measurably faster than Palm's own HotSync Manager for Windows -- nearly 50% faster in some tests. And the jSyncManager is 100% pure Java. And the parsing code for the protocol stacks and d
Re:Huh? (Score:3, Insightful)
Right for *YOU*? (Score:2, Insightful)
As this is a typical Slashdot wankathon story.... (Score:5, Informative)
Swt is crap [hacknot.info]
and
Swing is crap [ahmadsoft.org]
Re:As this is a typical Slashdot wankathon story.. (Score:2)
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.
Re:As this is a typical Slashdot wankathon story.. (Score:2)
I don't know how many of these are SWT problems, and how many are just incompetence o
Re:As this is a typical Slashdot wankathon story.. (Score:2)
Re:Bittorrent is not an SWT program (Score:2)
Advantages and disadvantages? (Score:5, Funny)
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)
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.
Re:None of the above. (Score:2)
Re:None of the above. (Score:2)
Swing (Score:4, Interesting)
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.
Java is an unfinished language? (Score:2)
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.
Re:Java is an unfinished language? (Score:2)
WinLAF (Score:2)
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].
Re:Swing (Score:2)
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
Re:Swing (Score:2)
Swing is maturing, SWT has growing pains (Score:4, Interesting)
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.
SWT if Sun would adopt it (Score:2)
AWT is a waste of time. It's just t
SWT vs Swing - no clear winner (Score:2)
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)
Re:Question (Score:4, Informative)
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...
Re:Question (Score:2)
Re:Question (Score:3, Interesting)
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
Re:Question (Score:2)
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)
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)
A thin client approach makes sense if:
Swing is never finished. (Score:2)
Call me back when it finally supports Clear Type.
Cheers,
Adolfo
Re:Swing is never finished. (Score:2)
June 2005 [java.net] it became available.
See also http://dabar.cowblock.net/archives/000365.html [cowblock.net] and http://java.sun.com/developer/technicalArticles/J2 SE/Desktop/mustang/ [sun.com]
Re:Swing is never finished. (Score:2)
A couple of years too late but at least they will fix it in a couple of years
Most typical client apps (Score:2)
A fourth option: SwingWT (Score:3, Informative)
Too many freakin' guis (Score:3, Interesting)
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)
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.
Re:Ugh (Score:2)
Re:Ugh (Score:2)
If you thought a bit more, you wouldn't have to sweat so much.
Deoderants are for the dirty +)
Re:None of them are very good (Score:2)
Re:None of them are very good (Score:2)
Re:None of them are very good (Score:2)
Sorry, didn't explain myself well. I was referring to the fact that a lot of people use Java or Flash instead of DHTML in places where DHTML is far more appropriate. This is especially common in the case of Flash.
Re:None of them are very good (Score:2)
Re:So even IBM can't handle the slashdotting... (Score:2)
Re:For the indecisive, SwingWT (Score:2)