1. AWT- Abstract Window Toolkit
2. Swing
3. SWT- Standard widget Toolkit
AWT [Abstract window toolkit]:
1. AWT tool kit is the part of java foundation classes [JFC]. Hence applications built using AWT toolkit works on all machines where ever JRE exists and does not require to install them separately.
2. AWT is the first and original java toolkit and a stable API.
3. AWT is a very simple tool kit with limited GUI components, layout managers and events. Sun people did not take even 2 months to develop the AWT tool kit
4. Some commonly used components like Trees, Tables, Progress bars does not exists in AWT. If required need to be developed from scratch.
5 AWT tools are heavyweight components. Heavyweight term can be defined as, it is the one that is associated with its own native screen resource (commonly known as a peer).
AWT components are thread-safe, which means you do not need to be concerned as to which thread in your application updates the GUI. This can eliminate many GUI update problems, but can make AWT GUIs run slower.
AWT allows you to build GUIs top-down or bottom-up or in any combination. By top-down, I mean creating a container component before any of its children. By bottom-up, I mean creating children before creating their containing (or parent) component. Thus, a component can exist without a parent container, and its parent can change over time.
AWT GUIs, in general, are not accessible. There is no API for an AWT programmer to specify accessibility information. Accessibility deals with how well an application can be used by people with disabilities. To be accessible an application, together with the platform it runs on, must enable PwDs to use the application with the appropriate assistive technologies (tools that provide alternate user interfaces). Many governments and corporations have standards that require applications to be enabled for accessibility.
Sun wanted the Java language to be a "write once, run everywhere" (WORE) environment. This means Java code could be developed and tested on one host (Windows®, for example) and be expected to run the same on any other Java host without testing. For the most part, Java technology succeeded, but AWT was a weak spot. Because AWT depended on host GUI peer controls (where each AWT component has a parallel host control or peer) to implement the GUI, the GUI looked and -- more importantly -- behaved differently on different hosts. This resulted in a "write once, test everywhere" (WOTE) situation, which was less than satisfactory.
Swing Toolkit:
2. Swing
3. SWT- Standard widget Toolkit
AWT [Abstract window toolkit]:
1. AWT tool kit is the part of java foundation classes [JFC]. Hence applications built using AWT toolkit works on all machines where ever JRE exists and does not require to install them separately.
2. AWT is the first and original java toolkit and a stable API.
3. AWT is a very simple tool kit with limited GUI components, layout managers and events. Sun people did not take even 2 months to develop the AWT tool kit
4. Some commonly used components like Trees, Tables, Progress bars does not exists in AWT. If required need to be developed from scratch.
5 AWT tools are heavyweight components. Heavyweight term can be defined as, it is the one that is associated with its own native screen resource (commonly known as a peer).
AWT components are thread-safe, which means you do not need to be concerned as to which thread in your application updates the GUI. This can eliminate many GUI update problems, but can make AWT GUIs run slower.
AWT allows you to build GUIs top-down or bottom-up or in any combination. By top-down, I mean creating a container component before any of its children. By bottom-up, I mean creating children before creating their containing (or parent) component. Thus, a component can exist without a parent container, and its parent can change over time.
AWT GUIs, in general, are not accessible. There is no API for an AWT programmer to specify accessibility information. Accessibility deals with how well an application can be used by people with disabilities. To be accessible an application, together with the platform it runs on, must enable PwDs to use the application with the appropriate assistive technologies (tools that provide alternate user interfaces). Many governments and corporations have standards that require applications to be enabled for accessibility.
Sun wanted the Java language to be a "write once, run everywhere" (WORE) environment. This means Java code could be developed and tested on one host (Windows®, for example) and be expected to run the same on any other Java host without testing. For the most part, Java technology succeeded, but AWT was a weak spot. Because AWT depended on host GUI peer controls (where each AWT component has a parallel host control or peer) to implement the GUI, the GUI looked and -- more importantly -- behaved differently on different hosts. This resulted in a "write once, test everywhere" (WOTE) situation, which was less than satisfactory.
Swing Toolkit:
Java Swing, also known as a part of the Java Foundation Classes (JFC), was an attempt to solve most of AWT's shortcomings. In Swing, Sun created a very well-engineered, flexible, powerful GUI tool kit. Unfortunately, this means Swing takes time to learn, and it is sometimes too complex for common situations.
Swing is built on parts of AWT. All Swing parts are also AWT parts. Swing uses the AWT event model and support classes, such as Colors, Images, and Graphics. The Swing components, layout managers, and events are summarized below (see Listing 4, Listing 5 and Listing 6). As you can see, these sets are far more extensive than that supplied by AWT and compares well to the SWT set.
To overcome the variation in behavior across different hosts, Swing minimized its dependence on host controls. In fact, Swing uses peers for only top-level components like windows and frames. Most components (JComponent and its subclasses) are emulated in pure-Java code. This means that Swing is naturally portable across all hosts. Thus, Swing does not typically look like a native application. In fact, it has multiple looks, some that can emulate -- although often not exactly -- different hosts and some that provide unique looks.
Swing uses the term heavyweight for peer-based components and lightweight for emulated components. In fact, Swing supports mixed heavy and light components in a single GUI, such as mixing AWT and Swing controls in the same JContainer, but care must be taken with drawing order if the components overlay each other.
Swing may not be able to take advantage of hardware GUI accelerators and special host GUI operations. As a result, Swing applications may be slower than native GUIs. Sun has worked hard on the performance of the recent versions of Swing (Java V1.4 and 1.5), and this disadvantage is becoming less noticeable. Because Swing's design is more robust, its code base is larger. This can mean it takes a beefier machine to run it than AWT or SWT might.
Beyond more components, layout mangers, and events, Swing has many features that make it more powerful than AWT. Some of the more important ones are:
Separation of model from the view and controller
For all components with models (such as buttons, lists, tables, trees, rich text), the model is separate from the component. This allows the model to be adapted to the needs of the application and for it to be shared by multiple views. Default models per component type are provided for convenience.
Programmable look and feel
Each component's look (appearance) and feel (how it reacts to input events) is controlled by a separate and dynamically replaceable implementation. This allows the look and feel of all or part of a Swing-based GUI to change.
Renderers and editors
Most components that show model content, such as lists, tables, and trees, can process model elements of almost any type. This is done by mapping a renderer or editor for each component type and model type. For example, a table with a column containing java.util.Date values can have special code to present the date value and edit the date value. Each column can have different types.
Accessibility
Creating a GUI that is accessible to people with disabilities is important. Swing offers an extensive infrastructure and API for enabling GUIs for accessibility. This support is independent of but integrates with the host accessibility support, if any.
Like AWT, Swing supports automatic disposal of GUI components. Swing also supports the AWT bottom-up and top-down construction methods.
Unlike AWT, Swing components are not thread-safe, which means you need to be concerned as to which thread in your application updates the GUI. If you err in thread use, unpredictable behavior, including user interface glitches, can occur. Utility routines exist to help manage threading issues.
Like AWT, one of Swing's advantages is that it comes standard with Java technology. This means you do not need to install it. Unfortunately, Swing has evolved a lot, so it is easy to become dependent on features provided in more recent versions of the Java language, which may force users to upgrade their Java runtimes.
SWT:
Swing is built on parts of AWT. All Swing parts are also AWT parts. Swing uses the AWT event model and support classes, such as Colors, Images, and Graphics. The Swing components, layout managers, and events are summarized below (see Listing 4, Listing 5 and Listing 6). As you can see, these sets are far more extensive than that supplied by AWT and compares well to the SWT set.
To overcome the variation in behavior across different hosts, Swing minimized its dependence on host controls. In fact, Swing uses peers for only top-level components like windows and frames. Most components (JComponent and its subclasses) are emulated in pure-Java code. This means that Swing is naturally portable across all hosts. Thus, Swing does not typically look like a native application. In fact, it has multiple looks, some that can emulate -- although often not exactly -- different hosts and some that provide unique looks.
Swing uses the term heavyweight for peer-based components and lightweight for emulated components. In fact, Swing supports mixed heavy and light components in a single GUI, such as mixing AWT and Swing controls in the same JContainer, but care must be taken with drawing order if the components overlay each other.
Swing may not be able to take advantage of hardware GUI accelerators and special host GUI operations. As a result, Swing applications may be slower than native GUIs. Sun has worked hard on the performance of the recent versions of Swing (Java V1.4 and 1.5), and this disadvantage is becoming less noticeable. Because Swing's design is more robust, its code base is larger. This can mean it takes a beefier machine to run it than AWT or SWT might.
Beyond more components, layout mangers, and events, Swing has many features that make it more powerful than AWT. Some of the more important ones are:
Separation of model from the view and controller
For all components with models (such as buttons, lists, tables, trees, rich text), the model is separate from the component. This allows the model to be adapted to the needs of the application and for it to be shared by multiple views. Default models per component type are provided for convenience.
Programmable look and feel
Each component's look (appearance) and feel (how it reacts to input events) is controlled by a separate and dynamically replaceable implementation. This allows the look and feel of all or part of a Swing-based GUI to change.
Renderers and editors
Most components that show model content, such as lists, tables, and trees, can process model elements of almost any type. This is done by mapping a renderer or editor for each component type and model type. For example, a table with a column containing java.util.Date values can have special code to present the date value and edit the date value. Each column can have different types.
Accessibility
Creating a GUI that is accessible to people with disabilities is important. Swing offers an extensive infrastructure and API for enabling GUIs for accessibility. This support is independent of but integrates with the host accessibility support, if any.
Like AWT, Swing supports automatic disposal of GUI components. Swing also supports the AWT bottom-up and top-down construction methods.
Unlike AWT, Swing components are not thread-safe, which means you need to be concerned as to which thread in your application updates the GUI. If you err in thread use, unpredictable behavior, including user interface glitches, can occur. Utility routines exist to help manage threading issues.
Like AWT, one of Swing's advantages is that it comes standard with Java technology. This means you do not need to install it. Unfortunately, Swing has evolved a lot, so it is easy to become dependent on features provided in more recent versions of the Java language, which may force users to upgrade their Java runtimes.
SWT:
SWT is a low-level GUI tool kit comparable in concept to AWT. JFace is a set of enhanced components and utility services to make building GUIs with SWT easier. The builders of SWT learned from the AWT and Swing implementations and tried to build a system that had the advantages of both without their disadvantages. In many ways, they succeeded.
SWT is a lot like AWT in that it is based on a peer implementation. It overcomes the LCD problem faced by AWT by defining a set of controls adequate to make most office applications or developer tools and then, on a host-by-host basis, creating emulated (like Swing) controls for any not supplied by the particular host. For most modern hosts, nearly all the controls are based on native peers. This means that an SWT-based GUI has a host look and feel, and host performance. This avoids the most widely held complaints with AWT and Swing. Certain hosts have low-function controls, so SWT supplies extended, often emulated, versions (often with "C" as the first letter in their names) to allow the more generally expected behavior.
SWT is different from AWT in how the peers work. In SWT, the peers are just wrappers on host controls. In AWT, peers can provide services to minimize the differences between hosts (this is where AWT ran into a lot of its behavior issues). This means that an SWT application is really a host application, with all the good and bad points that entails. It also means that SWT does not fully achieve the WORE goal; it is more a WOTE solution. That said, SWT does a remarkable job of creating a portable solution, albeit not as well as Swing.
SWT is a lot like AWT in that it is based on a peer implementation. It overcomes the LCD problem faced by AWT by defining a set of controls adequate to make most office applications or developer tools and then, on a host-by-host basis, creating emulated (like Swing) controls for any not supplied by the particular host. For most modern hosts, nearly all the controls are based on native peers. This means that an SWT-based GUI has a host look and feel, and host performance. This avoids the most widely held complaints with AWT and Swing. Certain hosts have low-function controls, so SWT supplies extended, often emulated, versions (often with "C" as the first letter in their names) to allow the more generally expected behavior.
SWT is different from AWT in how the peers work. In SWT, the peers are just wrappers on host controls. In AWT, peers can provide services to minimize the differences between hosts (this is where AWT ran into a lot of its behavior issues). This means that an SWT application is really a host application, with all the good and bad points that entails. It also means that SWT does not fully achieve the WORE goal; it is more a WOTE solution. That said, SWT does a remarkable job of creating a portable solution, albeit not as well as Swing.
