AWT vs Swing vs SWT

AWT, Swing and SWT are three main User Interface development technologies in Java. All three can be used to develop the desktop applications. Now the question is, which one to use and when? Each of these has its own pros and cons. In this article, we shall try to understand the pros and cons of each of these.

Let us start with AWT being the first Java GUI toolkit. It comes with standard Java packaging and hence no specific installations are required. This is the simplest form of GUI toolkit, where Java provide basic set of components, layout managers, events etc to design the desktop application.

AWT is dependent on host GUI controls (native peers). For every component in AWT, one equivalent host GUI control is built. This means, AWT directly utilizes the GUI control features set provided by host and is entirely dependent on this for available features. That is why it is called Heavyweight components library. As all the host does not support all the UI control, Sun decided to provide the least common denominator from all the UI controls available on different hosts. This means that AWT is having very limited set of controls and even lacks the generally required components nowadays like Tree, Table etc. If any application needs any of these components, it needs to be develop from scratch. That is a big task to develop the components which are quite commonly required in all kind of applications.

Various positive points of AWT are:

• It is very stable toolkit
• It is thread safe, which means it can work well in multi-threaded environment also. 
• It disposes the controls automatically, so application need not to worry about it.
• UI in AWT can be created in any sequence using bottom up or top down i..e we can start from parent to children or from children to parent; in any order actually. 

Negative points are: 

• As it uses host UI controls for representation of the components, it is dependent on host for the look and feel of components. That means, we can not ensure same look and feel across the platforms. Hence it fails the main motive of java to 'write once and run everywhere' (WORE). 
• As mentioned above, availability of various components is also limited due to availability of controls with various hosts.
• AWT UIs don't provide accessibility support.
• AWT is thread safe, but this feature comes at a cost of performance. Access needs to be synchronized.

After discussing the pros and cons of AWT, let us move towards Swing which is the next fantastic API in Java to develop the UI. Swing comes after AWT, hence obviously Sun has tried its best to eliminates the drawbacks of AWT as much as possible and to make it more extensible and rich in features. Swing is built by using the basic constructs from AWT; like it uses its event model and basic classes. But it is much more advance in design, rich features set and rendering / model concepts.

Most significant change comes with Swing is the lightweight library of components. As described above, AWT components were heavyweight as these were having host UI control for each of component in AWT. Swing overcome this shortcoming by providing lightweight components all defined in Java memory space and having complete control on their features, and rendering mechanism. This eliminates the dependency of components on host. Now developers can give any look and feel to the components and that can be same across the platforms. Feature set is also not limited to host but is defined by programmers using Java and hence carry great potential. With these changes, it open a new arena of Swing component development with many and many components coming with Swing and from custom libraries also; all written purely in Java - carrying WORE principle. This was the major achievement for Swing.

Here are the pros for Swing:

• A lightweight component library all developed in Java. Host UI controls are used only for top level containers like JFrame, Window etc
• Supports the Java motive to write code once and run everywhere by providing the feature to define the look and feel of components programatically, which can be similar for all platforms
• A vast set of components with advance features
• A more robust design
• Division of component structure in Model, view and controller. Now one model can support multiple views. 
• A good support for accessibility
• Introduced the concept of renderer and editors for various components like Table, Tree etc. Now renderer and editor can be overridden to provide customize feature for look and behavior of these components. It also helps in performance improvement using flyweight pattern.

Few cons of Swing:

• Swing is not thread safe. Hence developers need to be careful while programming in multi-threaded environment about not to call the Swing methods in different threads other than Event Dispatcher Thread. If it is not followed, behavior can be quite unpredictable as multiple threads would be doing the UI update without synchronization.
• This design is intentional to improve the performance. Thread safety comes at the cost of performance by making flows synchronized for threads access. Swing remove this and change the design to work in single thread model. However, it still support implementing heavy/time consuming work in different threads and later integrate the results to Swing UI using different utilities. 
• As Swing is not using the native UI controls, that means it can not take the advantage of optimization at host level, like hardware graphic acceleration etc.

Then comes the SWT (Standard Widget Toolkit). SWT is designed with an intention to use the best of both the world i.e. AWT and Swing. SWT uses the native controls for all the available UI components on a host, and this way it gains the edge in performance. The components, for which native controls are not available on hosts, SWT provides emulated components. However, with evolving hosts, most of the components now are supported by host native peers. Difference between AWT and SWT is that AWT peers (wrappers for host controls) are providing some extra functionality also wherever required, however, in SWT, peers are just the wrappers for the host controls and hence borrowing all functionality directly from host.

Pros of SWT:

• It tries to take the advantage of both the world from AWT and Swing by using the all possibly available host UI controls (which helps in performance) and by providing emulated components for the rest.
• It is well integrated in Eclipse environment.

Cons are:

• SWT does not come with Java standard packaging and hence needs to be installed separately.
• It does not support automatic disposal of components like AWT and Swing. Hence everytime developer needs to dispose the component or its parent.
• SWT rendering and model design for various components like Tree and Table is bit difficult to grasp and implement. 
• SWT has various libraries like GEF and Draw2D to support the advance drawing operations. But it is not as good as Java 2D and 3D APIs.
• In SWT, most of the components contructor takes the parameter called style. It is to choose the specific set/style of features from available features. However, as it is supplied at construction time; it makes the whole scenario quite rigid. We can not change it later mostly.
• It is not that open for the programmers which have a habit to read the source code to learn, because it uses the native peers for many features.

With these description, and their pros and cons; every technology has its own place. One can choose as per her requirement. However, in term of features, flexibility and extensibility; Swing is still doing well comparatively. Comments are welcome to add more to this discussion.

People who read this post also read :