Slashdot Mirror
SWT, Swing, or AWT - Which Is Right For You?
An anonymous reader writes "Why is there more than one Java GUI tool kit? The best answer is that one size does not fit all, nor is there a one-size-fits-all GUI tool kit to be invented soon. Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience. Read descriptions of each tool kit's basic features, and the pros and cons of using each."
Fuck off, I hate you all
Sincerely, GTK
I offer apologies for not naming the widget set I like best. Let's just call it UnderConstruction.
so there's no story, really.
When the server is "under maintenance". Why not delay the story for 5 hours or whatnot?
1: Make free software.
2: Take a poo.
3: ?
4: Profit!
Just in case someone actually wants to read TFA:w ww.ibm.com/developerworks/opensource/library/os-sw ingswt/+awt+swing+swt+features+opensource+site:www .ibm.com&hl=en&gl=us&ct=clnk&cd=1&lr=lang_en
http://72.14.207.104/search?q=cache:Sdg9JPdYswMJ:
I'm lovin' it!
You don't have to go with those, there are java bindings for everything!> QT, wxWindows, even curses!.
Pick the one you like!
evil is as evil does
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!
Horns are really just a broken halo.
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).
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?
Since SWT is not available on Win64 it is Swing.
SWT : buy
Swing: hold
AWT : sell
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.
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).
Shouldn't the question be "Which is right for your project?"
.... let me post two opposing sides of the swing vs swt debate:
Swt is crap
and
Swing is crap
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.
Buoy 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.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Although in beta, the pure java LGPL'd SwingWT http://swingwt.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.
Our apologies The IBM developerWorks Web site is currently under maintenance. Please try again later. Thank you.
Anyone can "stand up for what they believe", but it takes a very brave individual to change what they believe. - Loundry
Our apologies
The IBM developerWorks Web site is currently under maintenance.
Please try again later.
Thank you.
Hehe.
SCO employee? Check out the bounty
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.
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.
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.
A Multiplayer Strategy Game for Mac OS X, Windows, and Linux
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.
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 - hey, it's based on Swing in fact
Why would someone want to do that? In the end, it's /. !
AWT is a waste of time. It's just too antiquated.
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.
sheep.horse - does not contain information on sheep or horses.
or even ncurses
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.
Karma: It's all a bunch of tree-huggin' hippy crap!
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/ . Even an idiot could design GUI from that. But hey designing good GUI is hard regardless of the API used.
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?
-= This is a self-referential sig =-
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
As a rule of thumb, the most important issue is multiple JRE/JVM management. If you have any issues with this, use SWT as it is not JVM/JRE dependent. On the other hand, SWT's got it's own set of problems...
Here is some of the issues involved.
Swing versions are JVM/JRE version dependent. You really need to ship a JRE with your app and make sure it is used.
In the real worlds, thats not always possible. Customer policies may prevent user control of the JVM's available.
Even when you can specify the JVM's available on client machines, you cannot always guarantee that the particular one that will be used with your application, or worse yet, that someone won't put in an upgrade to the JVM that breaks everything.
It is not uncommon to patch the JVM for specific fixes like memory leaks. You have no idea whether or not the JVM/JRE you are running on is vanilla or not.
Of course, there are lots of other issues involved with using SWT, mostly due to it's immaturity. Don't try real serious OPENGL stuff unless you wanna do a lot of debugging.
And don't even get me started on embedding Windows apps in SWT programs. It can be done, but, in my experience at least, bug detection requires a Russian Roulette approach unless you write your own code. Some things work, work partially or work for a while and then trash some OTHER program.
One interesting suggestion:
If you can pull it off, write your GUI code is some stable environment like VS.NET and call functionality in Java via web services or other remoting technologies.
The talent pool for skilled GUI developers is a lot larger.
They basically created a layout manager that would play well with the IDE, as well as be a good layout manager on its own.
-- ac at home
Okay, ominous patent-protection aside, how does any of these Java GUI packages stack up against System.Windows.Forms? Or even Gtk# for that matter? The posts in this thread talk about how one is difficult to learn, one is deprecated, the other is hard to learn, none of them correctly GC and tend to leak, etc, etc.
.Net developer, so I have a certain liking for objects that just "go away" when you don't want them anymore. A lot of the issues raised here are ones that I don't worry about.
I'm a
So, if I wanted to go Java (which is a real possibility) what kind of battle am I facing to switch over? No one here is making it sound like a bed of roses! Feel free to flame me for my choice of technology, but can you at least throw in some useful information in your roast?
It rocketh. Check out Activegrids IDE for the feeling: http://sourceforge.net/projects/activegrid
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
I don't know how many of these are SWT problems, and how many are just incompetence on the part of the Azureus developers, but since sourceforge lists it as the most active project I am inclined to believe the former. I have used Swing apps on OS X, and Java/Cocoa apps. The former look slightly non-native, and don't feel native, while the latter look and feel native. Neither are anything like as bad as Azureus.
[1] How do you leak CPU? I find it hard to even picture the kind of design that would do this - perhaps adding things to the run loop and not removing them? Anyway Azureus (Java/SWT) and Psi (C++/Qt) both manage this on OS X.
I am TheRaven on Soylent News
There's quite a few books on choosing frameworks, here's one.
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
in the middle of the swt is crap they say the official bittorrent is a major user of SWT... Bittorent is made in python, no swt here. Maybe they should put Eclipse as a major user of swt, after all IBM made the toolkit for it.
I have no sig and I want to scream
A big developer complaint with Linux is that there are so many GUI toolkits to choose from, they all look different, and have different APIs. With Windows it's different: one standard API, one look and feel. Business developers like that. Java, with its proliferation of different, different-looking GUI toolkits, is suffering from the Linux problem. That makes it less attractive as a deployment platform for real-world applications. For most applications which will be delivered to Windows desktops, the best choice is to use Windows Forms on .NET.
And don't say web apps. Web apps suck. Their UIs do not scale up to the heavy-duty data entry people do in a corporate environment; they tend to require too much mousing around. Browser Web form usability just isn't up to the standard established by GUI apps, particularly when it comes to keyboard navigation.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Did you even read the linked article from the story? No, the SWT Sucks article is not FUD, it's 100% true in basically everything it covers. I use both Eclipse and a Swing-based text editor, Eclipse is far slower than the Swing application. There, proof that SWT is slow.
But if you read the article, you'll discover that Swing is far superior to SWT. They offer a feature comparison, which is basically a giant list of things that you can do in Swing that you can't do in SWT. Swing is more robust is absolutely everything compared with SWT.
After reading that article, I have no idea why anyone would ever use the SWT. It's slower than Swing, it's less feature-rich than Swing, and it's more complicated than Swing. Why would you ever want to use that?!
I use Azureus under Windows, and this application actually got me interested in SWT because it's the best looking Java app I've seen. I'd have to agree that this points to a SWT problem. Azureus 2.4.0.0 is out -- you could hope they've made some progress :-]
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
I didn't realize Azureus was an SWT app. I did, though, realize it was unusable, at least on OS X. It eventually (and seemingly inevitably) manages to completely monopolize the computer. Every once in a while I try a new version, but it's been a while since the last time, so maybe things have improved.
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.
Got Code?
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, but Swing solved a lot of GuI performance problems that plagued AWT. Nowadays Swing is an integral part of Java and comes "for free", and the memory issues don't mean as much when you're using computers with gigabytes of RAM. Meanwhile the performance issues of AWT have been largely solved by improvements to the JVM. As for SWT, it seems to me like an extra class library to have to load and run, with native bindings. Kind of the worst of Swing and AWT combined, although many people like using it.
I am a bit biased towards Swing, doing everything on Mac OS X. Apple has implemented class library caching and sharing, and they've hardware-accelerated a bunch of the Swing drawing. I recently ran some of my Java stuff on an Intel-based iMac Duo and things ran lightning fast; seemed almost faster than Carbon stuff. Almost.
The best Java widget set I ever used was Marimba's Bongo, back in '97 or so. It was fast, lightweight, extensible, and even included its own sweet VB-like interface editor. Like so many other great early Java libraries (remember JGL, anyone?) it was killed by Sun's insistence that they were about to ship their own widget set with java, which pretty much put the kibosh on third-party widget set development. Two years later, we finally got... swing. Which is just one of the reasons I haven't written a line of Java code in over four years. -p
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.
Swing is ugly, period. Why? Because it does not follow user's preferences and standard look&feel. Most of the previous posts seem to assume that the API is important. It is not. What is important is whether the user will like using your application or not. And, sorry, but most of the users are on Windows, and there is a standard look&feel Swing does not follow. Therefore, the users won't use your Swing application. Ever wondered why Java had so much trouble breaking through on the client side?
If you remember that most of the applications don't have to be run on all platforms, but only on some specific ones (Windows, MacOS), and that most of these applications won't need to be run from a webserver (common! my mother won't install a webserver just to use Excell nor to start her tax computing tool!), you only have the choice between .Net and SWT. Why? Because both are able to display a transparent red scrollbar if the user decided that all scrollbars should display that way. I want my Windows users to start a Windows application, not a Java application. I want my MacOS users to start a Mac application, not a Java application. They don't care about Swing or SWT, they really don't! But they want their nice-looking transparent red scroolbars!
Swing is a nice toolkit when you code software for other coders, or when your target audience is running Linux. For the remaining...
Yes I read the article. Its a pile of crap as articles go. First up it claims that issues with the UI based on only two applications. It doesn't go into details what those UI related issues are, but as someone has pointed out one of the apps isn't that great to begin with on a mac. Eclipse is probably one of the best examples of how SWT works. I am also using Workplace 2.6 Beta (which can render SWT via HTTP I might add) and it is on par with most windows apps.
Limited Functionality? He doesn't detail in anyway how it is limited in relation to Swing. All he details is coding differences. Likewise the only thing he can come up with is that you can't put an image + text on a button at the same time.
sorry but the article is airless bamf. Something a bit better then "I use both Eclipse and a Swing-based text editor, Eclipse is far slower than the Swing application. There, proof that SWT is slow." please.
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
Gregory Casamento
## Chief Maintainer for GNUstep
Unfortunately, they're both right.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
That should say some are missing features and some have bugs.
I mean give me a break, haven't all the other companies moved on? Sun can't even get a 2D gui control toolkit together and it's 2006. This should have been one of the first things they did.
Did they really want to keep having ugly, weird working scrollbars, no-colour, no style interfaces unless the programmer spends as much time on the gui as the rest of the program? If yes then success is at hand.
Personally I would just raise the bar and consolidate.
Sun, question to you: how long did it take to figure out that you restrict programmers on the use of the if statement? I'm sure you and several 3rd parties could have had a thousand if packages, IMAGINE THE CHOICE!!! You would have ruled my friend!
Stuck in the past, stuck in the past. I don't see other mature companies still wrestling with evolution on 2D gui toolkits. You're still in the playground on that.
"The nice thing about standards is that you get to choose from so many." Should be your motto.
whatever
I think that in the desktop world, there isn't such a thing as a portable application. Programming in Java helps writing for multiple platforms, but there is a huge amount of work that will have to be platform-specific.
Even if you are programming in Swing or even in SWT, you will to write native code or handle native code. Here are some examples:
If you do mean to build an app that runs on a Mac, you will need a Mac.
I cannot think of a java application that I have used that has not been ugly. The UI people often do not make the best programmers and the programmers often suck at designing good UI. And, WHY THE FUCK CANT YOU COMPILE JAVA INTO AN EXE?
You are right in saying that "You really need to ship a JRE with your app and make sure it is used"
Actually, I have seen very few programmers recognize that. That supports my point that there isn't such a thing as a fully portable desktop application.
In addition to the problem of JRE that you mentioned:
I like Swing, mainly because it can be easily extended to do things with components they were not originally designed for. You can fairly rapidly build a relatively complicated user interface, with custom components, custom events, and multiple interacting display windows, and still have perfectly manageable, re-usable code. (Well, if you work outside graphical designers, which in my humble opinion should only be used for developing write-only code.)
I agree that it can take an effort to master it, and that developing simple interfaces can take extra time because of the overhead. But Swing's structure is quite ordered and I have found that Swing suits "my" logic; it comes fairly natural to me as a programmer.
I like Swing much more than AWT, which IMHO was not very good at all, mainly because the event handling model was awful. For me the biggest problems with early versions of Swing were in the use of images, and while the image handling libraries are much more powerful and rationally organized now, they are also unpleasantly complex. But it is good enough. I have never tried SWT.
Web interfaces are nice for many applications, but for most of the things I do not really an option. For database applications a pretty good middle way seems to be Java Web Start, which allows you to use a web server to distribute your code, but still to run it as a very flexible application on your desktop.
I use both Eclipse and a Swing-based text editor, Eclipse is far slower than the Swing application.
Yeah, sure. Eclipse vs a text editor... And my C-64 boots faster than a Linux box with dual Xeons.
Not the one the poster linked to, the one that IBM wrote and is linked in the Slashdot article. When IBM says SWT sucks, and they wrote it, perhaps you should listen to them. It's IBM DeveloperWorks explaining that you should use Swing and not SWT. The IBM article contains a LONG list of features that SWT is simply missing.
Unless you have to, stay away from Microsoft products. It sounds awefully narrow-minded, but why deal with a mega-corporation that doesn't give a &#$ about their 3rd-party developers when you have a world of less legally-entangled tools to work with? Patents or none, microsoft, unlike Sun, looks at 3rd-party developers like customers, not 'co-workers.' Having the apache project and IBM's support behind Java make it all the more attractive, even if its not the best language for many things (client-side apps especially). Microsoft is so haphazard about backwards-compatibility I always have to wonder if anything I wrote a year ago is still going to work under the latest upgrades and patches. It's the monopoly-tax. Don't pay it unless you're getting paid well to do so!!
Probably because you haven't installed the compiler. Google for "Java native code compiler" or try Excelsior JET.
Ever tried to open a print dialog on linux with SWT? After spending a few days learning SWT I stumbled upon this bug which has been known for over three years. https://bugs.eclipse.org/bugs/show_bug.cgi?id=2479 6/
So much for SWT apps being portable even between the platforms that they support!
It's not so bad on Windows - at least in terms of look and feel. It's definitely the least hideous Java app I've seen - in fact the only one I've ever carried on using after trying it. It has some non-standard appearance here and there (e.g. tabs).
But it still manages to, e.g. fail to redraw the main list view controls properly when you drag other windows over it. Like, really badly. Like great swathes of window area being left empty and unrendered. I'm not sure how you manage to screw up something as basic as that so badly.
Which doesn't fill me with confidence about SWT, tbh.
AWT: old, based on OS controls but didn't do a brilliant job of doing it cross platform. Age means its the best choice for portability (e.g. it will run on both the MSJVM shipped with many versions of windows and virtually every sun jvm)
SWING: built on some of the very basic awt classes (container window frame and applet) with a widget set written in 100% pure java, consistant behaviour accross operating systems but even if you choose the platform look and feel its still a clone and there are liable to be subtule differences between your app and native apps. Also has a reputation for being slow (which was undoubtablly true with some versions though i belive this has improved) can run with things like the msjvm provided you are prepared to put up with downloading the swing classes.
SWT: also based on the native gui components but didn't try to be quite as deep an abstraction so will generally run faster and be more familiar to those used to writing native code. However as a third party library using its own native code it cannot be used for stuff like browser applets or java web start.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Even OpenLaszlo (widget system using flash, and being open-source) can be good for this, enabling a good user interaction (just like a real desktop app), and permitting to use any server-side language to do the right job...
:) (as well as AJAX, but with less work, since you use real widgets)
I mean, isn't that a good solution ?
Just getting a little political here, the "no big government interference/industry knows best" conservative political point of view hasn't worked here. And it's not just an academic question, this sort of thing degrades productivity, which means everybody is less efficient.
Oh sorry, I forgot, there already is a standard GUI interface, from Microsoft. Never mind.
Ben in DC
"It's the mark of an educated mind to be moved by statistics" Oscar Wilde
Two simple reasons:
.NET falls over on Windows 2000 due to the system handle limit. It gets slow quite a bit before that. It's possible to workaround, but takes quite a lot of code.
.NET 2.0 improves on this; we were using .NET 1 though.
.NET 1's Windows.Forms.
1. Get to 10000 widgets (easy: a list of 400 little control panels did it), and then watch as
2. Extremely crap layout.
Gtk# does not have the handle limit, and has much better layout than
Unfortunately, it's still slow at things like updating a hundred table cells, and its table/tree widgets are very limited in what can go in the cells.
The ideal widget set in my experience would have a lot in common with the rendering, styling and layout done by a web browser. Which is, in my opinion, another reason why AJAX is popular. (The underlying logic is obviously far from ideal, though).
-- Jamie
You say you using Swing because you're writing applets.
I've used AWT, because some of the web browsers I was deploying to didn't have Swing. That was a couple of years ago.
Is Swing ubiquitous with all browsers these days? What versions? (Or a link to a site would be handy).
Cheers,
-- Jamie
Sorry to disappoint, but I know .NET developers who've moved between Windows.Forms and Gtk#. There's also WxWindows.
.NET application on Windows.
You could say that Windows.Forms is the only native one, most widely used etc. That's true. It's also not particularly bad, and has many clever features, and good integration with tools, and some parts of it have clearly been thought through.
But it also has a surprising number of limitations and crapnesses, that mean it's not always the best choice even for a
Saying Windows.Forms is just like Sun saying to use Swing: it's the official line, but not everyone's doing it, and an informed developer must consider the alternatives if there are people actively using them for some practical (i.e. non-religious) reasons.
-- Jamie
I generally use AWT or Swing. I use AWT for the main reason that it was what I had originally learned when I started using java and had no idea how inheritance worked. I now find using Swing alot easier and alot more user friendly. Its a much more powerful widget set and why shouldn't I use it? Its the upgrade to AWT. Hopefully they'll phase out AWT in the near future.
Warning: Corny karma killing post above.
Since the answer is obvious... the preferred depends on the task at hand. 7337 h4x0r5 use both.
Run and catch, run and catch, the lamb is caught in the blackberry patch.
Sorry I missed the bit where it said SWT sucked. All it reads is comparing the two technologies and telling you where one is better then the other in what situation. Unlike the Poster I was replying to which was trying to state that SWT was full out rubbish but not having anything to support that claim.
Cincom's VisualWorks is so much better than most Java IDEs and GUI libraries, it is like comparing a sportscar to a square wheeled horse drawn wagon.
o ntent=smalltalk
A non-commercial version is available at http://smalltalk.cincom.com/downloads/index.ssp?c
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.
Which one? I don't use any of them: Java is bloated crap.
Personally, I generally avoid using AWT directly -- but it supports many things that you marked as "N/A". For example:
p s/R-3.1.2-200601181600/index.php#swt ) doesn't even show my server platform (FreeBSD) on the list...
Display an image -> java.awt.image.BufferedImage
Display text and image -> java.awt.image.BufferedImage
Generic container of other controls with a border and title -> java.awt.Frame
Add items to the system tray -> java.awt.SystemTray
etc etc
Also, while you do comment on the fact that SWT doesn't come with the JDK, you say "If you are developing only for one platform, SWT has an advantage in host compatibility"... that's not quite accurate... IBM has been notoriously behind on JDK implementations (ie: how long until it supports the JDK1.6 features?). The SWT FAQ says that it is built on JDK1.4, so it is already 2 major versions (a few years) out of date. Also, their download page ( http://download.eclipse.org/eclipse/downloads/dro
Personally, if the library requires a native download, I'm not using it -- too much hassle to maintain.
http://www.google.com/profiles/malachid
Thanks for your comment. You know a lot more about Linux installers than I do.
"You need to qualify what is an installer."
I mentioned "desktop application", but I actually meant desktop application for the consumer market. So, by extension, I was referring to installers that verify system requirement, let you choose installation options, install the application on your hard-disk, create icons, etc. I really wish computers were easier to use. I agree that Swing performs pretty well given the constraints it put on itself (non-native widgets, pure-Java rendering). However, there are glitches that programmers must deal with if they are targeting the consumer market. Here are more detailed examples:
The Java API for fonts under Windows is unfinished. I have Myriad and Myriad Pro installed (very popular fonts, one is TrueType, the other is OpenType), but the Java Environment v5.0 won't see those fonts. Also, some wide-spread PostScript fonts make the JVM crash.
Say you want your application to launch Acrobat Reader to view a PDF. Is Acrobat installed? The registry will tell you under Windows. You will need some platform-specific code to find if Acrobat Reader is installed.
Often, it is important that users find a familiar environment when using their applications. I find Swing's color chooser and open/save dialogs too different from their native versions. (In the Swing UI on which I work, the Open/Save dialogs are actually SWT, therefore they look completely familiar to the user.)
Too often I'm in conflict with other programmers who won't see the importance of small details in the user interface. They will choose a technology assuming that it will have no effect on the user experience.
GridBagLayout
*wretch*
to write a sufficiant wrapper to give a java applet the interface expected for a .net applet and compile it along with the applet using J#?
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Browser Web form usability just isn't up to the standard established by GUI apps, particularly when it comes to keyboard navigation.
Have you investigated adding accesskey and tabindex attributes to your site's forms? Or are you talking about your competitors' sites' forms? Or are you talking about some use of forms to which accesskey and tabindex do not apply?