Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Zonk posted more than 8 years ago | from the choose-wisely dept.

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."

cancel ×

323 comments

Sorry! There are no comments related to the filter you selected.

SWT AWT Swing (0, Funny)

Anonymous Coward | more than 8 years ago | (#14803084)

Fuck off, I hate you all

Sincerely, GTK

I like native widgets (1)

BadAnalogyGuy (945258) | more than 8 years ago | (#14803085)

I offer apologies for not naming the widget set I like best. Let's just call it UnderConstruction.

site down (0)

Anonymous Coward | more than 8 years ago | (#14803086)

so there's no story, really.

Whats the point of a story... (0)

Anonymous Coward | more than 8 years ago | (#14803087)

When the server is "under maintenance". Why not delay the story for 5 hours or whatnot?

Bussinessmodel? (0)

Anonymous Coward | more than 8 years ago | (#14803093)

1: Make free software.
2: Take a poo.
3: ?
4: Profit!

Re:Bussinessmodel? (0)

Anonymous Coward | more than 8 years ago | (#14803222)

More like

1. Take a poo
2. Call it free software
3. ?
4. Glory!

Google Cache (2, Informative)

ReverendRyan (582497) | more than 8 years ago | (#14803094)

Re:Google Cache (1)

qbwiz (87077) | more than 8 years ago | (#14803109)

Did you just insult IBM?

Re:Google Cache (1)

ChunderDownunder (709234) | more than 8 years ago | (#14803324)

Not given that at the time of posting the URL advises
The IBM developerWorks Web site is currently under maintenance.

Re:Google Cache - why? (0)

Anonymous Coward | more than 8 years ago | (#14803291)

Why would someone want to do that? In the end, it's /. !

System.Windows.Forms (2)

fyrie (604735) | more than 8 years ago | (#14803096)

I'm lovin' it!

Re:System.Windows.Forms (1)

ocelotbob (173602) | more than 8 years ago | (#14803106)

Tell me why I, using my Linux box, or using my Mac, should love features of a proprietary patent-encumbered language? Clock's ticking.

Re:System.Windows.Forms (1)

TheWanderingHermit (513872) | more than 8 years ago | (#14803129)

Because you might be a developer who writes programs that other people use, instead of just toys for your own system. And some of those users just might need a cross platform language and GUI. Or you might have to develop in Java for a number of reasons.

Re:System.Windows.Forms (1)

ocelotbob (173602) | more than 8 years ago | (#14803164)

I think you're a bit confused here, or I was unclear. I was responding to a poster who was asking about system.windows.forms, not SWT or Swing. Java's GUI features are useful, I was trying to glean insight as to how a silly feature of a silly by and large windows-only programming language would be useful.

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

kingkade (584184) | more than 8 years ago | (#14803209)

Java programmer here. There is a Free project called Mono which is implementing most of .NET, even the non-standard WinForms is also emulated and they are offering alternatives with other GUI toolkits like Gtk#. Mono targets many platforms. Again, I'm a Java programmer and even I know this. I think diversity's good. Competition's good. What do you think the main driver is behind JSF? Yep, .NET's WebForms.

Re:System.Windows.Forms (1)

ocelotbob (173602) | more than 8 years ago | (#14803253)

I know about mono and they themselves say that certain pieces of Windows.Forms are patent-encumbered and require workarounds. Why would a developer want to put himself at risk for patent litigation when there are other cross-platform solutions that work just as well and don't rely on methods that are in a legal grey area?

Re:System.Windows.Forms (0)

Anonymous Coward | more than 8 years ago | (#14803344)

I'm a mono developer. I'd appreciate a list of said patents.

Oh? You have no clue what these hypothetical patents are? what a shock...

Re:System.Windows.Forms (1)

kingkade (584184) | more than 8 years ago | (#14803355)

Patent-encumbered? Care to cite a reference? FUD, plain and simple; sounding like a robot, echoing the groupthink. It'd seem sad if it weren't so scary.

WinForms was not submitted as a standard .NET API, that's true.

SWT provides a wrapper around native Win32 APIs also, does that make it "patent-encumbered"? Now if you mentioned that some of the older .NET APIs used long Handles or just seemed Windows-centric in some way then I'd have some respect for your argument. In fact boredom is the only thing keeping me amusing myself like this originally trying to find some useful information from you but that ship has sailed. Later.

Re:System.Windows.Forms (1)

killjoe (766577) | more than 8 years ago | (#14803374)

MS has hinted at various "intellectual property" around the .NET platform. They have flat out said that they intend to vigorously defend their intellectual property (both gates and ballmer have said it). When asked outright whether they intend to hold the mono project harmless from patent litigation they have refused to give them blanket immunity.

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 somewhat compliant .NET implementation which will soon catch up with the oldest .NET implementation from MS. By the time vista comes out mono will be so far behind it will be a joke.

Re:System.Windows.Forms (1)

kingkade (584184) | more than 8 years ago | (#14803397)

Like I said: WinForms may have a bit of platform-specific code that may be depended on but there are no patents. which is the whole point. MS hinting and not giving "blanket immunity" is not unusual. Look at Sun and the JCP. If you're interested, go here for info about what Mono is: http://www.mono-project.com/FAQ:_General [mono-project.com]

Re:System.Windows.Forms (1)

ocelotbob (173602) | more than 8 years ago | (#14803515)

If there are no patents involved in winforms, then why does Mono's own page on licensing [mono-project.com] say there are patent issues involved with Winforms?

Re:System.Windows.Forms (1)

killjoe (766577) | more than 8 years ago | (#14803363)

Would you use it in a production environment? Me neither.

Re:System.Windows.Forms (1)

kingkade (584184) | more than 8 years ago | (#14803400)

Would you use it in a production environment? Me neither.

That's great. Answering you're own question, I mean. I guess you don't need me.

Re:System.Windows.Forms (1)

daliman (626662) | more than 8 years ago | (#14803175)

If you read your GP [slashdot.org] , the post makes more sense. They weren't attacking the java sets, they were attacking windows.forms; which is not, last time I looked, particularly cross platform...

Re:System.Windows.Forms (1)

jma05 (897351) | more than 8 years ago | (#14803379)

System.Windows.Forms is not a language.

Re:System.Windows.Forms (1)

Trejkaz (615352) | more than 8 years ago | (#14803392)

They said "features of".

Re:System.Windows.Forms (1)

CaptnMArk (9003) | more than 8 years ago | (#14803119)

Gtk# is better.

Re:System.Windows.Forms (1)

DrXym (126579) | more than 8 years ago | (#14803349)

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.

Re:System.Windows.Forms (1)

Overly Critical Guy (663429) | more than 8 years ago | (#14803126)

My NIB files are laughing at you.

Re:System.Windows.Forms (0)

Anonymous Coward | more than 8 years ago | (#14803159)

Amen! WPF is coming soon too :)

Re:System.Windows.Forms (1, Interesting)

Anonymous Coward | more than 8 years ago | (#14803229)

Then you'd probably like SWT. It falls to the least common denominator: Windows forms.
I don't know why anyone actually enjoys programming winforms. Do you like writing resize functions? Then changing them all the time?

Personally I'd take gtk over about any other toolkit. But of the ones in this article Swing is clearly the strong winner. The only thing I find horribly lacking in it is actually the listener mechanism. Having one function handle every event for an object is just messy when it comes down to it.

But, since Java doesn't support function pointers or multiple inheritance, implementing an action listener is about all you can do. And to do that, you have to only have a finite number of functions to make the user implement.

And for those obsessed with toolkit mechanisms from 1987, Swing supports a "null" layout manager, so you can just put crap wherever via pixel positions.

And, you might wanna realize that Microsoft is coming halfway to the modern world with WPF. They now support a dynamic resizing system, based on a tabular form for your widgets. They line up with each other, and are pulled to things. I guess gpu's are fast enough to calculate a spinning rubix cube with a different video on every side, but heaven forbid you write a real layout system ;).

And hence, you'll have resizing apps at the cost of almost no performance, and little learning. But unfortunately some of the widgets may look _really_ STUPID when you make the window very tall.
The point: Kiss winforms goodbye, you're about to get halfway to a real UI toolkit!

Maybe next they'll come halfway to a real HIG!

Re:System.Windows.Forms (1)

DrXym (126579) | more than 8 years ago | (#14803343)

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 job than they do of trying to visually design a form with a layout manager installed. I consider the VE plugin for Eclipse to be a fairly good form designer but even that can be hellishly confusing especially if you flip from one layout model to another.

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

perkr (626584) | more than 8 years ago | (#14803491)

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? (4, Insightful)

killjoe (766577) | more than 8 years ago | (#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? (4, Funny)

penguin-collective (932038) | more than 8 years ago | (#14803141)

Yeah, trouble is, no matter which you pick, you'll still be programming from Java.

Re:Is none of the above an option? (0)

Anonymous Coward | more than 8 years ago | (#14803292)

Well it could be worse, you could be targetting the CLR!

Re:Is none of the above an option? (1)

StarfishOne (756076) | more than 8 years ago | (#14803304)

Perhaps you could try Jython. :)

Re:Is none of the above an option? (0)

Anonymous Coward | more than 8 years ago | (#14803389)

Or maybe Jash... :P

Re:Is none of the above an option? (3, Informative)

ultranova (717540) | more than 8 years ago | (#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.

Re:Is none of the above an option? (1)

killjoe (766577) | more than 8 years ago | (#14803337)

They need to download a JRE anyway so what's the big deal.

Thin is IN (1)

Heembo (916647) | more than 8 years ago | (#14803120)

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!

Re:Thin is IN (1)

LnxAddct (679316) | more than 8 years ago | (#14803247)

I recommend you download the Java 1.6.0 beta called Mustang. Swing is not only now multi-threaded and fast as hell, but it also takes on the native appearance perfectly regardless of your platform or theme.
Regards,
Steve

curses (1)

appleLaserWriter (91994) | more than 8 years ago | (#14803396)

or even ncurses

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

dood (11062) | more than 8 years ago | (#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).

Re:Why is AWT even an option? (2, Interesting)

roman_mir (125474) | more than 8 years ago | (#14803178)

Oh, really? No reason at all? About a year ago, I had to work on a project [altsoftware.com] for Christie Digital [christiedigital.com] through Alt Software. The project was about building software that controlled video input from multiple devices into the same computer (I tested with 70 simultaneous inputs, this was possible because the hardware used overhead busses from input cards to output cards,) and video output onto rear-projector TV Video Walls. The software had to be designed in a way that supported multiple different platforms (windows/linux/unix.) So the front end was written in Java - this piece handled the windows, channels and profiles, it handled all the user interface issues. In the middle there was cross-platform C++ for video thread handling and resource management, and the back-end was all platform specific C code (basically device drivers from different vendors.)

So I did prototypes with Swing and found that there were problems with JNI Canvas handling. It wouldn't work properly but it did work with AWT. The Canvas had to be drawn in a specific color (magenta,) so that when the window handle was passed through JNI to C++, that code could pass the window handle further to the C drivers, that would draw on top of the magenta color within the window (on the Canvas.)

Re:Why is AWT even an option? (1)

BiggerIsBetter (682164) | more than 8 years ago | (#14803258)

Which begs the question, why not use a crossplatform GUI toolkit as well?

Re:Why is AWT even an option? (2, Informative)

DrSkwid (118965) | more than 8 years ago | (#14803303)

I'm sorry, I can't see your circular reasoning.

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 /. and your relatively low UID.

Re:Why is AWT even an option? (0)

Anonymous Coward | more than 8 years ago | (#14803357)

From your very own Wikipedia link:

Modern usage

More recently, to beg the question has been used as a synonym for "to raise the question", or to indicate that "the question really ought to be addressed". For example, "This year's budget deficit is half a trillion dollars. This begs the question: how are we ever going to balance the budget?" This usage is often sharply criticized by proponents of the traditional meaning, but has nonetheless come into sufficiently widespread use that it is now the most common use of the term.

Arguments over whether the newer usage should be considered incorrect are an example of debate over linguistic prescription and description.

Re:Why is AWT even an option? (1)

DrSkwid (118965) | more than 8 years ago | (#14803378)

*sigh*

Another reason to stop using wikipedia.

Re:Why is AWT even an option? (1)

Trejkaz (615352) | more than 8 years ago | (#14803403)

I don't think it's okay to use an excuse which amounts to saying "but heaps of other idiots do it".

Re:Why is AWT even an option? (0, Offtopic)

ChunderDownunder (709234) | more than 8 years ago | (#14803508)

Please stick to the topic at hand, namely Swing vs SWT.

The link you supplied states that the parent's phrase is a modern usage and that
"Arguments over whether the newer usage should be considered incorrect are an example of debate over linguistic prescription and description."

Unless your doctorate is in linguistics, who are you to prescribe its usage?

Ugh (0, Troll)

Hellraisr (305322) | more than 8 years ago | (#14803135)

While we're at it, why don't we take a poll on who uses solid deoderant vs deoderant spray vs gel deoderant.

Next topic: which linux distro do you use?

Re:Ugh (0)

Anonymous Coward | more than 8 years ago | (#14803156)

...why don't we take a poll on who uses solid deoderant vs deoderant spray vs gel deoderant.

Next topic: which linux distro do you use?

There must be a word that would describe the mutually exclusive propositions of polling people who use deoderant versus polling people who have a favourite Linux distro.Maybe it's conceptually oxymoronic.

Re:Ugh (1)

lanswitch (705539) | more than 8 years ago | (#14803196)

Only when they make a deodorant by the name of "Conceptually Oxymooronic" I'd consider using some.

Re:Ugh (0)

Anonymous Coward | more than 8 years ago | (#14803301)

I won't need to be reminded to stay upwind of you! I am sure your odor will precede you.

Re:Ugh (1)

narcc (412956) | more than 8 years ago | (#14803238)

What about roll-on? You insensitive clod!

Re:Ugh (0)

Anonymous Coward | more than 8 years ago | (#14803263)

This is Slashdot you're talking about! What the heck IS deoderant?!

Re:Ugh (1)

DrSkwid (118965) | more than 8 years ago | (#14803317)

To paraphrase Tesla :

If you thought a bit more, you wouldn't have to sweat so much.

Deoderants are for the dirty +)

No Win64 SWT (1, Informative)

Anonymous Coward | more than 8 years ago | (#14803143)

Since SWT is not available on Win64 it is Swing.

Re:No Win64 SWT (0)

Anonymous Coward | more than 8 years ago | (#14803192)

thats interesting, seeing as SWT is written in java, and java code is totally portable... http://www.eclipse.org/articles/Article-SWT-Design -1/SWT-Design-1.html [eclipse.org]

Also. Who needs all these widgets anyway? I fly with System.out.print();

Re:No Win64 SWT (1)

randyjg2 (772752) | more than 8 years ago | (#14803475)

Actually no, there is a binary component to SWT because it wraps native widgets. When you download the libraries, you have to download the SWT library appropriate for your platform. 64 bit support for windows is (sorta) under development See bug 57151 for the remaining issues

https://bugs.eclipse.org/bugs/show_bug.cgi?id=5715 1 [eclipse.org]

My six word summary (2, Interesting)

MillionthMonkey (240664) | more than 8 years ago | (#14803145)

SWT : buy
Swing: hold
AWT : sell

Huh? (5, Informative)

Yaztromo (655250) | more than 8 years ago | (#14803174)

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? (1)

Iffy Bonzoolie (1621) | more than 8 years ago | (#14803252)

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.
I think you mean abstract the native widgets for a set of platforms, not obfuscate.

-If

Re:Huh? (1)

Solra Bizna (716281) | more than 8 years ago | (#14803275)

Ever write an AWT program?

-:sigma.SB

Re:Huh? (1)

Iffy Bonzoolie (1621) | more than 8 years ago | (#14803305)

Yes. I agree, it sucks. But, the phrasing of that particular jibe just didn't really make sense as it stood. I really didn't know if he was trying to make a point, or was just using the wrong word.

-If

Re:Huh? (1)

Yaztromo (655250) | more than 8 years ago | (#14803320)

think you mean abstract the native widgets for a set of platforms, not obfuscate.

You are, of course, quite correct. It has just been one of those days, I suppose :P.

Yaz.

Re:Huh? (1)

Lobais (743851) | more than 8 years ago | (#14803371)

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

Personally my experience with swing is that it is very logical and easy. Only problem is that being written directly in java, it doesn't fit into many desktops. The new ocean theme is much better than the metal one, but it still looks very wrong in, lets say, a gnome desktop.

Re:Huh? (1)

TheParanoidOne (190293) | more than 8 years ago | (#14803514)

There is a GTK look and feel ...

Re:Huh? (1)

pdoubleya (139876) | more than 8 years ago | (#14803372)

Just one correction: Swing was based in (large) part on Netscape's Internet Foundation Classes, which were Netscape's attempt to have a cross-platform GUI component set. Sun and Netscape worked out some deal and Sun took this over, and re-worked and re-branded it as the Java Foundation Classes. See the Wikipedia article here [wikipedia.org] . Cheers! Patrick

Re:Huh? (1)

jez9999 (618189) | more than 8 years ago | (#14803433)

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

Re:Huh? (2, Informative)

Yaztromo (655250) | more than 8 years ago | (#14803497)

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 then replicate a similar system in Java for designing and describing Java GUIs. Now that Java 1.5 has java.beans.XMLEncoder available, this should be significantly easier for them to accomplish.

GUI development in Java is still painful and problematic. Which is too bad, as I'm actually a proponent of Java on the desktop (although IMO only Apple has got this right, with their JAR Bundler tool, such that you can distribute a Java application to users such that it appears to them to be just like any other application -- they never have to be even be aware that it's a Java application).

Yaz.

Re:Huh? (1)

tjansen (2845) | more than 8 years ago | (#14803504)

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.

None of them are very good (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14803179)

I would rather use a web front end than use any one of the three (and I have used them). Java on the client is too cumbersome and support intensive and the majority of users do not like them. Throw a nice dhtml front end at them and they are much happier (at least in my experience).

Re:None of them are very good (1)

jinxidoru (743428) | more than 8 years ago | (#14803408)

I agree that many things that are done in Java need not be done in Java. Flash is actually the most common offender in this category. Unfortunately, DHTML cannot handle anything and everything. Any client application which needs to do intensive processing is not going to be able to be written in DHTML. Of course, you can just make the web-application do everything for you, but why make your servers work so hard when your client has so many free CPU clicks?

Re:None of them are very good (1)

hookedin (715162) | more than 8 years ago | (#14803425)

I agree, at least for the appearance. Each time I have a reason to use Swing or SWT, I end up wishing that either of them would just render HTML. For one thing, there are decent WYSIWYG editors out there, which I've yet to find for Swing.

In general, a markup language is easier to use than widgets. If I code a page manually I can do 90% or more of it without looking anything up, but with Swing I frequently have to consult a reference to figure out which widget to use and all of the methods and properties needed to get it to behave the way I want.

Re:None of them are very good (1)

stony3k (709718) | more than 8 years ago | (#14803458)

You might want to try the new visual Swing editor in Netbeans 5.0. I know, everyone uses Eclipse (even though it doesn't support half the things Netbeans does). The new visual editor really rocks.

Right for *YOU*? (2, Insightful)

devjj (956776) | more than 8 years ago | (#14803182)

Shouldn't the question be "Which is right for your project?"

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

tonywestonuk (261622) | more than 8 years ago | (#14803183)

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

Swt is crap [hacknot.info]

and

Swing is crap [ahmadsoft.org]

Re:As this is a typical Slashdot wankathon story.. (1)

forgotten_my_nick (802929) | more than 8 years ago | (#14803451)

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.

Advantages and disadvantages? (5, Funny)

kwerle (39371) | more than 8 years ago | (#14803191)

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. (4, Interesting)

seebs (15766) | more than 8 years ago | (#14803200)

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.

Re:None of the above. (1)

shutdown -p now (807394) | more than 8 years ago | (#14803338)

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.

For the indecisive, SwingWT (1)

Lknight (125949) | more than 8 years ago | (#14803202)

Although in beta, the pure java LGPL'd SwingWT http://swingwt.sourceforge.net/ [sourceforge.net] attempts to replicate the Swing API (and it's huge) using SWT code. You distribute your platform specific swt library with your build, make sure it's in the searchable path (./binlib for example) and you're good to go. The AWT api is replicated as well.

So even IBM can't handle the slashdotting... (1)

Sinbios (852437) | more than 8 years ago | (#14803205)

Our apologies The IBM developerWorks Web site is currently under maintenance. Please try again later. Thank you.

IBM slashdotted! (1)

wfberg (24378) | more than 8 years ago | (#14803218)

Our apologies

The IBM developerWorks Web site is currently under maintenance.
Please try again later.

Thank you.


Hehe.

Swing (4, Interesting)

Anonymous Coward | more than 8 years ago | (#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.

Java is an unfinished language? (1)

Futurepower(R) (558542) | more than 8 years ago | (#14803279)

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.

Re:Java is an unfinished language? (1)

eneville (745111) | more than 8 years ago | (#14803476)

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.

WinLAF (1)

Trejkaz (615352) | more than 8 years ago | (#14803421)

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] .

From a Technical POV... (1)

DimGeo (694000) | more than 8 years ago | (#14803254)

In SWT it is easy to make plugins, because the components can and do get GC'ed after you properly dispose() of them. In Swing, many components are immortal, i.e. (J)Dialogs and (J)Frames are particularly stubborn. They are kept in some AWT Vector's inside the innermost painting loop and never die (hint: Sun, what about using WeakReference-s where appropriate? I know, not always possible, may break apps, etc.). On the other hand, if you forget to dispose() some SWT component, you end up with lots of leaks in your app. If you want plugins, learn resource management, and use SWT. You can go with Swing as well, but be prepared to require a restarts when a plugin is updated, only you will have to make the classloading on your own. If you want to write portable, static GUIs for Java, Swing is the way to go, as it is much, much easier to use.

Re:From a Technical POV... (1)

ChunderDownunder (709234) | more than 8 years ago | (#14803306)

In SWT it is easy to make plugins, because the components can and do get GC'ed after you properly dispose() of them. In Swing, many components are immortal, i.e. (J)Dialogs and (J)Frames are particularly stubborn. They are kept in some AWT Vector's inside the innermost painting loop and never die

Really? I thought that was the purpose of java.awt.Window's dispose() [sun.com] . If they are out of scope they should then get garbage collected.

Swing is maturing, SWT has growing pains (3, Interesting)

BortQ (468164) | more than 8 years ago | (#14803276)

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.

It's not just the toolkit, it's the tools (0)

Anonymous Coward | more than 8 years ago | (#14803290)

If you want to build a GUI application, you need help. Yes you can do the entire thing with pure javax.* classes and emacs, and if you're very experienced with the tools, this is a perfectly fine way to go, but for less-experienced developers (ie, most of us) we need some help putting the app together. What I am suggestig is that which one you choose (SWT or Swing) is less important than having a good GUI builder tool. Swing without Matisse (NetBeans) is painful and tricky. Swing with Matisse is quite enjoyable to work with. I'm sure there are comparable tools for SWT that also help.

That said, I would go with Swing because it runs everywhere. You can't use SWT in an applet, etc. With a good tool there's no reason not to use Swing. SWT used to be faster, but that is no longer the case. Swing is as fast as native desktop apps, and it looks good, too. With Java 6 (ocming soon) it will have even better native look-and-feel because it will use more of the native toolkit.

Btw, the original poster was on drugs for putting AWT in the same category as Swing and SWT. AWT is at a lower abstraction level. It is not a GUI building kit. It is a kit for putting primitive stuff on the screen. If you want to write a GUI app you would use AWT, but as a layer under Swing.

------------
Upload images and videos [draganddropupload.com] - hey, it's based on Swing in fact

SWT is a go (1)

max909 (619312) | more than 8 years ago | (#14803323)

Looking at the perfomance, and the acceptance by the opensource community (Azerus etc) it seems SWT is a winner. And, as far as my experience is concerned, the definate winner is also SWT. The speed, and the advantages of Native UI are definately non - ignorable.

SWT if Sun would adopt it (1)

DrXym (126579) | more than 8 years ago | (#14803335)

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 too antiquated.

SWT vs Swing - no clear winner (1)

AndrewStephens (815287) | more than 8 years ago | (#14803373)

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 application like Eclipse I would be tempted to use SWT, since the installer could handled the SWT specific issues.

Java programmers really should not be complaining about having two first-class GUI APIs.

Question (4, Interesting)

Orlando (12257) | more than 8 years ago | (#14803479)

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?

AJAX (2, Insightful)

SoupIsGood Food (1179) | more than 8 years ago | (#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
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?