I understand that this question is rather general and kind of a holy war. Could you explain to me why SWT is successful when AWT is not, while these two frameworks use the same idea of native ui controls. What makes SWT different comparing to AWT? Just few words if possible.
Thank you.
AWT is the original cross-platform, native-peer based GUI widget set. It drew a lot of complaints for not being perfectly consistent across platforms. Sun built the Swing widget set to answer those concerns, building it with pure Java (no native peers), but people complained that it was slow and ugly.
IBM built SWT as a native-peer based competitor to Swing. It succeeded because it looks good, performs well and is pretty consistent across platforms. It cemented it's position by getting used by many popular applications, Eclipse and Vuze being the most obvious.
SWT provides a lot richer set of native heavyweight widgets than AWT - a proper comparison would be SWT vs AWT/Swing. Due to that, SWT looks more native than AWT/Swing. While this could be considered a success, it can also be a drawback, depending on what you need to implement. In case of SWT you are using only heavyweight native widgets with all possible OS limitations. With AWT/Swing you have the option to mix lightweight Swing (pure Java) widgets with native AWT widgets for better performance.
Related
I'm developing on a legacy Java desktop application mixing Swing and AWT controls. I can successfully apply the system look and feel to Swing controls of course, but can I do the same for AWT ones? If not, can I implement some bridge in any way?
The basic answer is "no". The AWT components are backed by native OS components, either directly (via OS supplied libraries) or indirectly (via AWT based native components). It's possible that AWT will be linked to "older" component libraries so some of the components won't match the current OS "look and feel", which will be using newer component libraries.
In either case, you can't effect how these components look (and certainly not through Swing's Look and Feel API).
Ok, this might be a little hear say, but The Story Of Awt says "Java's GuiToolkit had to use the native widgets provided by the host window system, whether Windows, Motif, or the Mac. Mimicking the look-and-feel in Java wasn't good enough; it had to be the real native components."
I am looking into developing an Java GUI for a biological analysis tool. My question is, Can I use both AWT and SWING libraries under the same Model View Control design pattern? Or,are they two libraries controlled in a distinct way? I would like to know If I can bring them in under the same roof for purposes of reusing existing code written with both libraries. Thank you very much for your time.
Swing is built on top of AWT, you can mix Swing and AWT and it will technically work, but with some limitations:
heavyweight vs lightweight components: components in AWT are heavyweight - they correspond to a native OS window. This means that all AWT components appear above sibling Swing components. (E.g. put a awt List and a swing JList in the same container, and the List will always appear above the JList.)
Look and Feel: the AWT components look and feel native, since they are native components. The Swing components have a pluggable look and feel, which defines their appearance and behavior. If you choose the L&F to match the native platform, these components are only "immitations" of the native look and feel, and can behave differently from their AWT counterparts. (E.g. JButton vs awt Button.)
For these reasons, it might be wise to use just one UI library, presumably Swing.
EDIT: JDK 6 (Update 12) offers seamless integration of heavyweight and lightweight components, so mixing will work seamlessly. So the first point is no longer true - but having inconsistent look and feel between the two UI toolkits still stands.
Hi Yes you can use both. But there is no need, even more it is highly not recommended to mix these two.
For example you can have some serious problems as AWT doesn't have 'depth' concept. No different layers, etc. Other problems are for example, look of components of these frameworks differs.
EDIT:
I am loving this resource. Go ahead and read it there are all issues mentioned, with illustrative examples, which you have to be aware of when you are going to mix these two. http://java.sun.com/products/jfc/tsc/articles/mixing/
Oi,Boro.
I am really confused over what to use. Options I see are awt, Swing and swt.
My question is which should be best for Desktop Java app on all platforms( Mac,Windows and Linux )with minimum platform dependent code ?
AWT is obsolete, though some of its classes and design form the underpinnings of the Swing API.
Here is my take on the differentiators between creating applications in Swing and SWT:
Swing
+ Forms part of the standard Java-SE platform, so fewer distribution headaches
+ You can create a consistent look and feel across platforms
+ Controls are lightweight, so creating your own is relatively easy
- If you need Swing applications to look like native applications, there may be a lot of work in it; Swing can be styled with a platform look'n'feel, but the results aren't always close enough for everyone's satisfaction
SWT
+ Easy to create simple applications which use native widgets
- Manual resource management
- You need to distribute platform-specific libraries
- You face the lowest-common-denominator problem - not all widgets are available on all platforms, so some will be custom to SWT anyway
Although I've put a lot more minuses against SWT, I wouldn't discount it. Which technology you pick will depend on your project requirements. Picking the library is only the beginning when it comes to UI development.
Swing is the easy, low-maintenance option and I'd agree with the other posters that this is probably the best fit for what you want.
Swing.
AWT is old and too low-level, SWT has native components, and doesn't ship with the JRE (it's a third-party library). Swing is high-level (-ish), and pure-java.
I would go with Swing as the best choice using what's packaged with Java. However, even Swing can make you jump through all the same hoops every time, so I would recommend looking into one of various frameworks that build on top of it and handle most of the boilerplate work of building an app.
There's a JSR for a Swing Application Framework which I have used when it was still in active development, but it's currently frozen. Their project page recommends a fork of that project, and another one called GUTS which uses Google Guice as its dependency injection. Netbeans also has Netbeans Platform.
I know the scope of these frameworks goes outside the realms of "UI", but they handle things like data-binding between your model and your UI which Swing does not do.
I need to compose a fairly simple GUI for a server monitoring process. It will have a few tabs which lead to a log tailing, counts of resources, and a start and top control. Nothing fancy here. Which Java framework, AWT or Swing, makes more sense for something this simple.
Swing is the way to go. It's a cleaner programming interface, and looks better.
Use Swing or SWT, since AWT has no tabs built in.
Starting with Java 6 Update 10, Swing got an entirely new look and feel, the 'Nimbus Look and Feel'. It looks great and is really fast because it uses vector graphics.
Swing is your best choice if you're stuck choosing between Swing and AWT.
If you have the flexibility, I would at least consider SWT. It's faster, matches the platform look and feel, and seems to have fewer porting hurdles and regression problems from release to release. There is a small hurdle in setting up your first project (getting the right jars and such), but other than that, it's no more difficult to work in.
AWT was the first Java GUI framework, it had a lot of flaws and was abandoned in favor of Swing. The main reason it is still in the JDK is for backwards compatibility and because some classes are re-used by Swing.
The future however (even for the desktop) could be JavaFX.
if you are planning to move your gui onto multiple platforms, then go with AWT. Otherwise, Swing gives you a much broader set of components to work with.
If you are looking for a better looking GUI, you can have a look at substance look and feel package in this address: https://substance.dev.java.net/see.html
Swing is good in many ways, then why do we need JavaFX?
There is both a technology part of JavaFX that will help design UIs, and a language part that will make writing UIs easier.
The JavaFX technology brings a 2d scenegraph and video capabilities. Afaik these will also be made available generally to java. They are good advancements for creating client side application with fancy and interactive graphical UIs. The 2d scenegraph should make it possible to create more graphic heavy applications that are still responsive.
The JavaFX language is a much better way off creating UIs programatically. Java Swing code can get very verbose, while the same JavaFX code will be smaller and easier to maintain. Closure support makes creating event handlers easier. Declerative assignment of settings makes configuration of elements easier. Native list syntax makes adding components easier.
Please note that I haven't really written any JavaFX, but I have read code and paid attention to what's going on. I recommend trying it yourself to find out what's cooking.
I think Staale's answer is a good start but I would add...
Use JavaFX if
1) If you're interested in developing the application for mobile or TV (note this has yet to be released)
2) If you're working with a graphic designer who is creating the appearance of the application in photoshop and you want to be able to import their look directly.
3) If making the GUI filthy rich is important to you. (so if you want a panel to fade in or out, or slide upon demand)
Use Swing if
1) You're creating an application mainly for the desktop.
2) Performance matters and you know what you are doing (so if you're writing an IDE, Swing would be a better choice)
3) You're looking for a RPC (rich client platform) to build upon.
It is the same reason why we have Java, C++, C#, Python, Perl, Ruby... although we already have C.