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:
No Win64 SWT (Score:1, Informative)
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.
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.
As this is a typical Slashdot wankathon story.... (Score:5, Informative)
Swt is crap [hacknot.info]
and
Swing is crap [ahmadsoft.org]
Re:System.Windows.Forms (Score:3, Informative)
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:System.Windows.Forms (Score:2, Informative)
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 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? (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: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:System.Windows.Forms (Score:3, Informative)
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 class or two from some JAR, the JVM will mmap() the entire JAR file, reserving virtual address space for all of it, even though only the pages that actually get read will be faulted in and consume real RAM. So several megabytes of virtual address space has been "consumed", but only a few KB of actual RAM is used.
I'm not trying to say that Swing doesn't use too much memory... just that its unlikely that your measurements are even remotely accurate. Probably the best way to get a realistic measurement is to have your system running as little software as possible, disable swap to keep that from clouding things, then add up your free RAM plus the RAM used for disk caching to get your total "free" space estimate. Then start your app and record the new total of free RAM plus cache. Do this several times and if the numbers aren't all over the place you'll probably be able to use the difference between the app-running and app not-running states as an estimate of memory usage.
Getting reliable app memory usage estimates out of systems with reasonably modern virtual memory systems is really hard. Even this approach tends to overestimate the real usage, becuse in order to avoid to much randomness you have to shut down every app possible. But in normal use, many of the libraries and files used by the app you're trying to get an estimate for will be shared by other applications, so a really accurate estimate should divide the cost of those items among the apps in some reasonable way.
A fourth option: SwingWT (Score:3, Informative)
Re:Question (Score:2, Informative)
It's not a stupid question.
Short answer: Because Java is meant to be cross-platform.
Long answer: I really don't want to re-write the ENTIRE GUI for each platform I port my app to. Would you? You're right, though - Java apps don't look like native apps. But that's a small thing to sacrifice for my app being able to run on almost any platform. However, they don't "behave" like native apps? Menu behavior is standardized. Buttons are standardized. They may not look the same, but they behave the same
Basically, you're using "re-inventing the wheel" is the wrong sense of the phrase, when it comes to programming. Sun can re-invent the wheel one time for each platform the JVM is ported to, or it can force you to re-invent the wheel for your GUI for *every* platform you want your app to run on. Pick one.
Re:Huh? (Score:3, Informative)
And just to further this point, modern JVMs will, if the OS allows it (like, say, Linux), mark unused pages as free for use by the OS. So, the JVM may allocate a very large hunk of memory, then, through garbage collection, free up a bunch of that memory and then release the pages back to the OS. However, process monitoring tools may not properly reflect this, and simply display the peak amount of memory the JVM has requested.
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 data types is pretty complex. We've had users running this code on old Pentium-class systems, and the execution speed is still on par with native solutions.
So yes, I've asked my users, and they're typically surprised that Java can be so fast. The key is having a developer who knows how to optimize code, with a sound design. Doing a lot of the heavy lifting work yourself doesn't hurt either (i.e.: not relying on a lot of external frameworks), as does using as much parallelization as possible.
Hav eyou tried Jake2, the pure Java version of Quake 2 [bytonic.de]? I have no speed issues playing it on my 1.33Ghz PowerBook -- it works like a champ.
Sorry, but Java speed complaints are mostly bunk. Swing does have some performance issues (although this can differ from platform to platform), but Java as a whole is quite fast. You simply have to have developers who know what they're doing when it comes to optimization and overall program design to make the most of it.
Yaz.
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:None of the above. (Score:2, Informative)
button.addEventLink(CommandEvent.class, this, "buttonPressed");
and every Java programmer should understand JavaBeans code likebutton.addActionListener(((ActionListener.class) EventHandler.create(ActionListener.class, this, "buttonPressed"));
Let's assume that I'm not to lazy to write a helper function to get rid of the casts in the JavaBeans version. Why would I want to use the Buoy event classes? Should I mix Buoy and EventHandler code when I want to use the more powerful EventHandler.create() variants?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.