Replace AWT with SWT ? - Java SE (Archived)

SWT is far better than AWT. It supports more native widgets.
So I think it can be quite interesting to use SWT instead of AWT.
Moreover, implements Swing components using swt. I like the Swing API but would rather use the native widgets swt offers.
Just my .02
G

Agree. AWT is a decade old, and it should be removed.
Build Swing on top of SWT it will give us finally a Java desktop application.

Is this feasible?  Sounds like a great unifier if it is.

I would also like to see the demise of AWT. SWT is what AWT should have been. But I really doubt if this would happen because:
1. Eclipse.org has not submitted SWT as a JSR. They do not have any plans to do so either.
2. As long as Sun controls the development of Java, SWT will not be incorporated as it would effectly mean the end of Swing (Swing became popular because AWT was too limited).

No i don't think one will dominate the other. SWT and Swing have there pros and cons.
Swing is not native, that means all applications look the same on all platforms. If you want a corpered identity for your applications you are lost with SWT, it's simply not possible. On the other hand if you want native look and feel you better use SWT.
Customizing Swing components is quite easy, doing the same with SWT is a pain because the components are native.
Thinking about testing, SWT applications testing effort is linear with the number of platforms you support.
SWT feels a bit snappier on most platforms because of the platforms optimizations in their native libraries.
I think SWT and Swing should both exist and they should use the same native interfaces. Swing needs some native interfaces anyway, and SWT would win a better tested base library.

There is no need to replace AWT with SWT, and it is impossible, due to the many reasons.
In Tiger, the "bridge" has been developed, allowing SWT to embed Swing.  So you can use either SWT or Swing, or you can mix them when you need that.  However, as you pointed out, Swing and SWT won't look and won't behave the same, so the possibilities to mix them efficiently are quite limited.  And if you don't plan to mix them - then what is wrong with SWT being developed as OS product separately?

> There is no need to replace AWT with SWT, and it is
> impossible, due to the many reasons.
Just how is it impossible?  What are the "many reasons"?
What it boils down to is choice.  Sometimes native widgets are the right choice, and AWT is very weak at the moment.  Java needs an up-to-date native widget implementation and SWT fits the bill.  The fact that SWT and Swing can run side by side, or even on top of one another, is quite nice as well.
http://sourceforge.net/projects/swingwt/
http://sourceforge.net/projects/swtswing/

If you said this 5 years ago i'd say you have a point, maybe...but Swing has really come a long way, and is improving every release, while SWT is really starting to show its age and seems pretty stagnant.

"but personally I don't see a standard Java IDE plug-in architecture until J2SE supports BOTH SWT and Swing in an interoperable fashion".
You could write a plugin that does the logic and two other plugins that does the UI, one Swing, the other SWT.
By default you could start with Swing and allow the user to switch to SWT.

> > There is no need to replace AWT with SWT, and it
> is
> > impossible, due to the many reasons.
>
> Just how is it impossible?  What are the "many
> reasons"?
You can not build a secure application with SWT because it uses native libraries.

The point is that there should be a [i]standard[/i] API.   Yes, Swing and SWT have different [i]implementations[/i] useful in different situations, but there is no good reason to have a two or three different APIs for creating a button or a combo box.
This fragmentation is hurting desktop Java.

The shift from AWT to Swing resulted in API fragmentation anyway, did it not? Another API won't hurt any more than that did. That the result looks and feels nice is a lot more important than a non-fragmented API.
Monika.

I agree with you when you say that we need SWT for building rich clients.
Right now it's just too hard to build nice looking and responsive GUI apps using Swing. And no matter how hard you try, a swing application would look and and behave different, and the user perceives this.
When considering the most downloaded java application, the one with most downloads is not JBoss, or Tomcat, but Azureus, a bittorent client with millions of downloads per month. And part of this success comes from the fact that it's gui is implemented using SWT.
If we could do a poll on users of a java application to see what UI they like more, the one done in Swing and the one created with SWT for the functionality, I am convinced that 90% would prefer the SWT GUI.

Related

the difference between "swing/awt" and "SWT"

What is the main defference between "swing" and "SWT",
in other word, when use them to implement a GUI,what is different?
Once making a choice between them,what do they affect a project? 
They both are GUI toolkits. One is from Sun, one is from IBM.
Sun's is lightweight, meaning all components paint themselves. IBM's is heavy weight meaning that all components are painted by the platform's native widget toolkits (there are exceptions to both of these, but just bear with me).
If you use SWT, you will need to create downloads for each platform your app was meant to run on, not only that, you will need to include the corresponding platform SWT jar files in your project. Ontop of that, SWT doesn't have anywhere near the documentation or help that Swing has (but to be fair, its about 1/8th the age of Swing).
If you are a great programmer that usually doesn't need help and can get by with a few good docs and MUST have native look and feel and fantastic GUI performance, then use SWT.
But if you are more relaxed and what to do the easiest thing, use Swing.
Both are good, I prefer Swing right now, but lets wait and see if IBM buys Sun.

Is AWT out of date ?

I am a newbie of Java language and studying GUI now. I am wondering whether it is worth reading AWT documentation. Sun's website recommend that we should use Swing components instead. So, do I need to read archive of AWT?
Many thanks. 
Swing is actually built on top of the core AWT libraries. Because Swing does not contain any platform-specific (native) code, you can deploy the Swing distribution on any platform that implements the Java 1.1.5 or above virtual machine.
Swing contains many more graphical components than its immediate predecessor, AWT 1.1. In addition, Swing contains many design advances over AWT. For example, Swing introduced an Action class that makes it easier to coordinate GUI components with their functionality. You'll also find that a much cleaner design prevails throughout Swing; this cuts down on the number of unexpected surprises that you're likely to face while coding.
Swing depends extensively on the event-handling mechanism of AWT 1.1, although it does not define a comparatively large amount of events for itself. Each Swing component also contains a variable number of exportable properties. This combination of properties and events in the design was no accident. Each of the Swing components, like the AWT 1.1 components before them, adhere to the popular JavaBeans specification. As you might have guessed, this means that you can import all of the Swing components into various GUI builder tools, which is useful for powerful visual programming.
The short answer: You should be familliar with AWT and the M-V-C paradigm to understand the Swing and JFC libraries.
JJ 
I humbly disagree. One can implement MVC with Awt or with Swing (or with Eclipse's SWT, which IMO, is better than both). Awt historically came before Swing, and indeed Swing improves on many of Awt's shortcomings. My general opinion is that if you want to build an applet, think Awt. If you want a standalone or Java webstart application, think Swing or SWT.
- Saish 
I humbly disagree. With which part?
One can implement MVC with Awt or
with Swing (or with Eclipse's SWT, which IMO, is
better than both). I was referring to how Sun implemented Swing on top of AWT.
Awt historically came before
Swing, and indeed Swing improves on many of Awt's
shortcomings. My general opinion is that if you want
to build an applet, think Awt. If you want a
standalone or Java webstart application, think Swing
or SWT.My answer came from the Java Swing, 2nd Edition By Brian Cole , Robert Eckstein, James Elliott, Marc Loy, Dave Wood.
The only reason I do not use SWT is its a non standard library, not shipped with the JDK. I also watched a web presentation from last years JavaOne conference and some of the developers of Swing talked about early versions of Swing, AWT, and SWT. What they said in a nutshell is the current version of Swing is not slower than SWT, like the early versions.
Hence I have adopted their opinion... and we all know what opinions are like...
JJ 
I humbly disagree. With which part?The part where you advised learning Awt first to better understand Swing (event listeners, I believe).
One can implement MVC with Awt or
with Swing (or with Eclipse's SWT, which IMO, is
better than both). I was referring to how Sun implemented Swing on top
of AWT.No disagreement there.
Awt historically came before
Swing, and indeed Swing improves on many of Awt's
shortcomings. My general opinion is that if youwant
to build an applet, think Awt. If you want a
standalone or Java webstart application, thinkSwing
or SWT.My answer came from the Java Swing, 2nd Edition By
Brian Cole , Robert Eckstein, James Elliott, Marc
Loy, Dave Wood.Presumably non-biased towards the use of Swing over SWT? :^)
The only reason I do not use SWT is its a non
standard library, not shipped with the JDK. I also
watched a web presentation from last years JavaOne
conference and some of the developers of Swing
talked about early versions of Swing, AWT, and SWT.
What they said in a nutshell is the current version
of Swing is not slower than SWT, like the early
versions. I have actually read the same, even on SWT sites. Speed, personally, is not my main concern, as the usual consumer of a client-side UI, for me, is a business user rather than a gamer. Rather, a 'native' interface for me is a higher priority. Business users generally are comfortable with Windows. SWT scores near perfect marks here. I understand that Swing as of JDK 1.4 is both more native in appearance (for Windows users at least) and faster. I have done a lot with Swing a while ago, and these concerns may very well have been addressed. But above and beyond and apart from all that, IMO, SWT is simply easier. I write less code.
Hence I have adopted their opinion... and we all
know what opinions are like...
JJDefinitely a fair point! :^)
- Saish

SWT vs Swing

Hi,
I am just curious what is the differences between SWT and Swing? Is one better than the other? If so, why?
I just want to get a better understanding of each and their advantages.
thanks 
Trying to start a flamewar? <grin>
To me, the main difference is that Swing uses lightweight components that are pure Java. That is, they are rendered by the library. In contrast, SWT uses heavyweight components that are rendered by the underlying operating system. That means that SWT components look and feel native, because they are native.
This leads to some basic pros and cons. For example, I think Swing has a more elegant API, compared to the thin "wrapper" API of SWT. (I should mention that there is a higher-level library that is built on top of SWT, but I'm not familiar with it. It's called JFace.) Also, you don't need to package any additional jars or libraries with a Swing application. In contrast, every SWT application needs a platform-specific jar included with it. So you need to create multiple jar distributions if you're aiming for cross-platform capability.
A major (IMO) drawback to SWT is that you have to manually manage resources for OS-dependent objects. This is a consequence of SWT's "wrapper" architecture; it doesn't use Java's garbage collection, you need to call dispose to free the resources.
On the pro-side for SWT, the benefits of having native look and feel are obvious. However, there are some very good Swing L&Fs, now. That includes L&Fs that copy the native L&F, and also completely separate L&Fs that don't try to copy a native L&F, but just look good. Another pro for SWT is that you can tightly integrate with a native platform. That might be a consideration if you are mainly targeting Windows, for example, and don't need cross-platform capability. For example, if I were writing a Windows Java application that used Automation to control Microsoft Word, I would pick SWT over Swing. On the other hand, if I were writing a Windows application to control MS Word, I might not use Java. I'd be considering things like Delphi and C#, and would probably lean towards Delphi (no big runtime necessary, like Java or .NET, good RAD capability, good Automation capability, et cetera).
I use Eclipse as my IDE, so I'm familiar with SWT, and initially favored SWT for GUI work. However, I've recently started leaning towards Swing. I like it because I prefer its design and API, it follows Java ways of doing things (e.g. garbage collection), and also because it is standard with J2SE (no additional jars).

AWT, Swing of SWT?

What should I use, AWT, Swing or SWT? And why?
What are the pro and cons? 
You haven't told us your requirements.
I don't know about the original poster, but I'd find it interesting to hear (read) a discussion on the pros and cons of each, from a general perspective.
Although, in this forum, there may be too many Swing advocates to get fair evaluation ;) 
Not sure what SWT is, but Swing vs AWT? Swing is better.
One of the major problems with AWT is that it had to create a peer object in the operating system for each object in Java. This created a very slow and heavy UI. Swing creates a peer only for high level containers like Window, Frame etc. Simple objects like buttons, dropdowns etc are basically "painted" onto the high level container and have no corresponding peer in the operating system. Fewer peers, greater performance, less memory usage.
So Swing is faster than AWT?
Is IBM's SWT faster than Swing? Or more powerful?
Should a company use Swing or SWT (or even AWT) for its merchandise planning and control system? 
Swing is not faster than AWT.
SWT is faster than Swing.
SWT is [probably] not faster than AWT, but it is more featuresome. 
I reckon AWT should be improved to the same level as Swing. Because the idea's good, the implementation is a little lacking in features.
I want menus with letters underlined (keyboard shortcuts), etc. 
Anyone who has used eclipse and Netbeans knows that SWT is hugely more usable and pleasing to the eye than Swing.
Sun, however, don't like SWT because (they say) it breaks the 'write once run anywhere' principle, which, in many ways, it does.
But do we, as Java programmers, care that much about this principle when it comes to non-web, client-side programming? Maybe we'd like something to run on Unix and Windows, and maybe a Mac? Fine! Use the GTK+ 2 versions, as well as the windows one. (I think there's GTK+ version for the Mac?).
It's okay if Sun don't approve of SWT, so long as they don't try to kill it. People using SWT will make it successful, so it's us programmers who have to show them what we want.
If you're wondering what SWT is, visit http://www.eclipse.org. SWT is a bit like AWT, except that it allows the programmer to use ALL of the features of the native widgets. This makes it harder to write cross-platform code, but allows the creation of very rich UIs.
Rhys 
Hi all,
I don't know SWT, but for me it looks like everybody worries much more about "pleasing to the eyes" UI than about real functionnalities of the programs...
Let's be serious: if you only intend "non-web, client-side programming", just return to VB and it'll be done mush faster...
My opinion is that SWING covers almost all of the "normal" needs for "serious" applications... and JAVA covers a huge part of "write once, run everywhere", wich is a great deal for developers.
Cheers. 
I have been doing some pretty heavy swing programming in the last few years and have a lot of respect, but recently I have started programming on the Eclipse workbench platform and am a convert.
A lot of people are talking about SWT, but that is only a piece of the picture. SWT does a pretty good job of mapping most of Swing's functionality. SWT is cross-platform (as long as you stay out of its OLE package) and unlike Swing, it actually looks like the platform you are running it on and it is very fast and actually feels like a native application.
On top of SWT is JFace. First off this is not like comparing AWT/Swing. SWT is a pretty complete package by itself. JFace adds in the few things that Swing had over SWT and in addition has formatters, specialized dialogs, wizards, preferences (Not registry based on Windows thank goodness), etc.
One thing that we haven't addressed yet is a platform to code on. When you build a Swing app, you pretty much start from scratch. Toss up a frame. Oh, you want help system? - code from scratch. Oh, you want to make it pluggable? - hit google and start researching.
Instead of all that work I suggest looking at the Eclipse workbench. It is kind of confusing at first since the default download is configured as an IDE (and a dang good one at that), but as you look closer, you see a fully developed application framework where the IDE is mearely a plugin that can be removed quite simply. The splash screen and all the "branding" can be easily changed and there are tutorials on eclipse.org that explain how to do it. The workbench gives you a lot of freebies like a context sensitive help system, plugin architechture, well developed application event system, and content management framework.
There was a bit of a learning curve when starting out with workbench programming (SWT and JFace should be pretty straight forward for seasoned UI coders), but the advantages far outweigh the cost of entry. 
I have had a look at eclipse and SWT, and I am impressed. But SWT has only very minimal image support, e.g. I could not find a way to access pixel data. As far as I know java.awt.image.Image or BufferedImage are not usable together with SWT. Is this correct?
Ingo 
The only drawback of swt is that there is no gui builder for swt, but it seems that it is no longer the case:
http://www.swtworkbench.com/index.shtml
http://www.swtguibuilder.com
So, for simple gui applications without MVC you should use swt. Otherwise use swing.
quereinsteiger,
I assume you had some notion of AWT, Swing, SWT before asking your question on this forum. If you did any research yourself before posting, however, it would have been nice had you listed resources you'd gone over so respondents would then, hopefully, add more material rather than regurgitate stuff. (IMO, a "didn't want to sway responses" argument doesn't hold water.)
For example, thus far in this thread all posts except that by "terrarealm" is mostly drivel. Uhh, couldn't find a more euphonious word... :)
The following article compares Swing and SWT: http://www.developer.com/java/other/article.php/2179061
--A                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Why JavaFX and not a new version of Swing?

In the company where I work we have tried do develop a real application (not just such a simple demo applet) with JavaFX and had to move to Swing. Please give me one reason, why I should use JavaFX instead of Swing. I have not found any reason. Why has Sun not just provided a new Swing (if not possible neglecting backward compatibility)? 
JavaFX doesn't replace Swing and is not intended to do Swing job. JavaFX is primarily made for RIA, something similar to Flash and Silverlight. Actually, JavaFX uses Swing components for those who want to use them (on desktop profile). If you are trying to develop a thick enterprise application, maybe you should use Swing not JavaFX. At some point, you will have to write many Java classes and communication between JavaFX and Java will cause you a headache.
When it comes to RIA, JavaFX is promising a lot because it supposed to work on any platform with J2SE or J2ME virtual machine installed. Not sure what are the minimum requirements for J2ME though. You can write one code that will mostly work on mobile,desktops and TV devices with minimal modifications . You just have to learn how to make it flexible enough.
Also, JavaFX is built upon the solid Java platform, so you virtually can do anything if you know how to use Java. For example, deliver 3D by using Java3D. 
The question "Why JavaFX" have been asked a number of times. Not sure if there is a good definitive answer...
The question "Why not a new Swing" is a bit more original.
Now, one might ask "why a new Swing"? What is not satisfying you in the current one? Why drop a robust GUI platform having shown its utility?
Now, it is a bit hypocritical, as others felt Swing wasn't enough and felt the need for something else, from SWT to Pivot, including Griffon, Thinlet and LWUIT (as seen in [Swing and JDK 7|http://blogs.sun.com/theplanetarium/entry/the_future_of_swing] article).
But I don't see Sun dropping years of development on Swing and starting something from scratch in replacement. They aim more at improving it, adding a Swing Application Framework, a TimingFramework or JXLayer (not sure if they are all official Sun projects though), not to mention other efforts like the various looks and feels or the Trident animation library. I see JavaFX as complimentary, not as a replacement, and it is still a bit green, with performance issues and nearly no native components (so still relying on Swing for real user input/structured output).
The answer to the question "why JavaFX" somehow is in the eye of the beholder.
I see Sun's marketing stuff (although I have skipped some of it), from being a strong RIA platform (read, unofficially, a Flash killer, hence the flashy stuff, rich graphics and animation capabilities) to "+Bringing Rich Experiences To All the Screens Of Your Life+", putting stress on portability, from the Web browser to the desktop, including the mobile platforms.
I also see the reactions and remarks of developers, in many threads of this forum and various articles on the Web.
Some expect to [develop a full desktop application with JavaFX|http://forums.sun.com/thread.jspa?threadID=5388304], but with current state it is mostly integrating Swing components in a "rich" box with added fluff.
Others see it more like a game platform. Others as a cool way to make widgets and lightweight interfaces (perhaps the most right approach).
You can also question "why a new language"? (lot of people asked it...)
I think the aim is to make something as easy to use to designer than to developers. The declarative nature of the language make it faster to learn than Java, and can be generated automatically from vector data (Illustrator export and such).
And the CSS styling goes this way, too.
And some features, like binding and on replace, ease development too (with a performance impact, alas).
(I typed the above before reading maennj's answer, which covers, unsurprisingly, some common ground.) 
You can use CRUDfx SDK for JavaFX. Aim of CRUDfxSDK is building applications for real life. See example database application at [http://jfxstudio.wordpress.com/2009/05/25/the-graphic-database-front-end-ii/|http://jfxstudio.wordpress.com/2009/05/25/the-graphic-database-front-end-ii/]

Categories

Resources