awt_swt_swing_java_gui

AWT, SWT, Swing: Java GUI Clean Up (1)

Overview

Java GUI toolkits have always been a controversial topic. The same type of debates also happened in other languages such as Smalltalk. In fact there exist such debates on every platform-independent language. It is especially prominent in Java because Java is the most dominating language today.

So what’s the controversy? Basically, it is a dispute between people who support emulated components(or widgets, or controls) and those who support native components. There are two camps among Java developers, one of which advocates for emulated components as in Swing, and the other native components as in SWT.

History

There are many stories about around the dispute on the Internet. You should probably have already heard of them.

One of them can help you to understand the whole picture. Let’s start with this one, in which Amy Fowler from

Swing team is one of the protagonists.

Back in 1990s, there were three companies, which developed their products using Smalltalk. They are IBM, Digital Talk and Parc-Place. IBM and Digital Talk adopted native components, while Parc-Place believed that emulation is the way to go. At the very beginning, all things went well until IBM overtook the others. The other two then merged to form a new company named Objectshare. Then a huge battle erupted when they tried to merge their products into one. The native and emulated crowd fought the battle nearly to death. When Amy Fowler from Parc-place, who insisted on emulated components, finally won the victory, IBM had got all of their accounts, because the two companies did nothing but quarrel for an entire year. The share price of the company, went down to under 1 dollar a share and were pulled from NASDAQ because of incorrect financial reportings.

At that time, AWT had just existed. Sun had built a basic set of portable control classes that mapped to native components on the different operating systems. However AWT was very buggy. It was beyond belief this was just poor code that could be fixed. Just then, Amy was hired by Sun, and she promised to solve all of the problems by doing a lightweight solution. Convinced, Sun management to make her the head of the GUI development. Amy then hired all her old Parc-Place friends and they set about creating Swing.

In IBM, Visual Age for Java were first written in Smalltalk, which used native components. Then they started to migrate them to a Java code. All of the IBM developers are the those Smalltalk guy, and they hated Swing for its emulated nature. They reluctantly built it using Swing. At that time, it is of no doubt that Swing was ugly, slow and buggy. Therefore they created a project to migrate the Smalltalk native components over to Java. This toolkit was later called SWT, which initially means Simple Widget Toolkit and later Standard Widget Toolkit. It was a success asthey released a product called Visual Age Micro Edition. The folks later found that there were bugs in Swing reading

windows events, which could cause memory leaks. So they took the decision that SWT and AWT/Swing should not co-exist and then put the toolkit into Eclipse which is a tools platform derived from the early Visual Age.

The above story should have given you an overview of the history of the three, especially SWT. Now you might

think, the reason IBM did to create SWT was valid and Swing should follow the way SWT has been on. Actually this opinion is very superficial. When you dwell upon to the nature of Java, you will find that it is not that simple as you

expect.

Prerequisite

What is the essential feature of Java, which has influenced the decision in the toolkit design? Or what is the

prerequisite of a java GUI toolkit?

The answer comes from one of Sun's promises about Java, write once, run anywhere. It is one of the java's

advantages over other languages. Before Java was created, software portability was a nightmare especially to those who wanted to support multiple platforms. It is especially true in modern days when the Internet is so popular. People from different parts of the world are working on different platforms. And it is very common for a software vendor to support multiple operating systems. Java’s write-once-run-anywhere promise was obvious a relief to developers. It can greatly improve software development productivity.

However to write a portable applications, you should use those standard libraries, which provide platform-independent APIs. These standard libraries include language support, common utilities, networking, I/O and GUI toolkit, etc. So when Sun started to design the GUI toolkit, the first thing it should consider is a well-designed platform-independent API. AWT and Swing were designed carefully in such a way to avoid platform incompatibility. SWT on the contrary was initially designed without this portability in mind. It was first designed for an IDE, Visual Age for Java. And at that time, it seemed that Windows was their first priority. Therefore SWT API is more akin those of Windows. In general SWT is not as portable as Swing. Although Steve Northover, the father of SWT, argued that SWT is platform independent, you can easily find many Windows API inheritances.Differences

GUI application is one of the major types of softwares. So Java GUI library should be standardized and integrated

into the JRE platform. However different operating systems have different GUI styles and component sets. There are some components which exist on all the platforms and have similar look and feels. These common components

such as button, label, textfield, checkbox, etc are also called standard components. Different gui toolkits provide different set of components. Same component from different toolkits may have different look and feel. GUI toolkit usually follows different principle when choosing component types and features to implement. When examining a gui toolkit, we generally have two different levels of concerns. One is component types, the other is component

features.

Terms

First let me illustrate two mathematical concepts to you: LCD and GCD. LCD means least common denominator.

GCD means greatest common denominator. Look at the figure below. There are three different sets standing for different Oses. The intersecting part is LCD of the three, while the union is GCD of the three.

Component Types and Features

Now let’s examine the component types and features of the three Java GUI toolkits, AWT, SWT and Swing.

AWT

AWT component set complies LCD principle, which means AWT only has the common set of components which exist

on all platforms. So you cannot find advanced components such as table or tree in AWT, because these components are not supported on some other platforms. As to feature set per component, AWT complies LCD too.

It can only support those features available from all platforms. For example, AWT buttons is not able to be attached with an icon, because on Motif platform, button is not supposed to have an icon.

Since its poor component and feature support, AWT did not attract developers much. And it is deprecated by Sun.

It is only there to ensure backward compatibility and support Swing.

SWT

One of SWT’s initial goal is to provide a more rich component set than AWT. It adopts GCD (greatest common denominator) principle to provide a union set of components that appear on every platform. The idea is that if a component type exists on the platform, then SWT will encapsulate it using java code and JNI call. If a component does not exist on the platform, it then emulates the component by extending and drawing a Composite. A SWT Composite is similar to AWT Canvas. By this way, SWT provides a richer component set than AWT. It is worth to point out that SWT JNI wrapper is different from AWT. Its emulation is also different from Swing.

As to component feature set, SWT is similar to AWT. They complies to LCD. In early SWT versions, SWT button did not support icon attachment for the same reason as AWT. But later, many of those missing features were made up using emulations. But still, there are features which cannot be implemented purely by emulation. SWT has its components completely controlled native operating system. It is hard to extend. Only features like some graphic decoration can customized by emulating. So strictly speaking, SWT component feature set can not be as rich as

Swing due to its difficult to extend.

Swing

Swing is the most powerful and flexible of the three. With respect to component types, Swing complies to greatest common denominator. Because Swing controls all of the GUI system and it is very extensible and flexible, Swing can almost create any component you could imagine. The only limitation of Swing is its AWT containers. In Swing you still can not implement real transparent or irregular-shaped windows, because Swing depends on those AWT top containers including Applet, Window, Frame and Dialog etc. Except these niches, Swing has implemented

almost all the standard components on every platform.

As to component feature set, Swing complies to greatest common denominator. It has most of the component features available on every platform. What's more, you can extend the existing Swing components and add more

features to them.

(To be continued ...)

AWT, SWT, Swing: Java GUI Clean Up (2)Implementations

The above comparison is mainly conducted in API level. Let's continue the comparison with focus on

implementation details. In all the difference between Swing and SWT/AWT is that Swing is purely implemented in Java, while SWT and AWT is a mixture of Java and JNI. Of course, their target is same, to provide a cross-platform

APIs. However to achieve this, SWT and AWT has to sacrifice some components and some features so that they can

provide a universal APIs.

AWT

An AWT component is usually a component class which holds a reference with a peer interface type. This reference points to a native peer implementation. Take java.awt.Label for example, its peer interface is LabelPeer. LabelPeer is platform independent. On every platform, AWT provides different peer class which implements LabelPeer. On Windows, the peer class is WlabelPeer, which implement label functionalities by JNI calls. These JNI methods are coded in C or C++. They do the actual work, interacting with a native label. Let's look at the figure. You can see that AWT components provide a universal public API to the application by AWT component class and AWT peers. A component class and its peer interface are identical across platform. Those underlying peer classes and JNI codes

are different.

SWT

SWT implementation also utilize JNI methodology. But the detail is different from that of AWT. SWT evangelists often became furious when they heard people describing SWT as another AWT. Steve Northover, the father of

SWT, once complained about this.

Yes, they are different. Let's delve into SWT code. In SWT, the only identical part on every platform is the component interface. That is class and method definition signature. All the underlying codes are different from platform to platform. SWT provides an OS class for every platform. This class encapsulates many native APIs by JNI methods. And then SWT component class glues these JNI method together to provide a meaning functionality.

For example, on Windows, text field selection can be conducted by only one system call. This system call is implemented in the Windows OS class as an native method. So there is only one JNI call in the setSelection method

of Text on Windows.

However, on motif platform, text selection involves two native calls. Again SWT implements these two calls in the motif OS class. So the component class on motif needs to call these two calls to achieve text selection.

By now, you can see the major difference between SWT and AWT is that they use different peer code to wipe out the differences. SWT uses java code, or java peer to glue system calls implemented by JNI. However, AWT put these code in native peers, which complicates the situation. I think SWT's method is more clever.Swing

When it comes to Swing, everything becomes clear and straight forward. Except the top containers, Swing

implementation depends on nothing of individual platform. It has all the controls and resources. What Swing needs is event inputs to drive the system, and graphics, fonts and colors which are inherited from the top AWT

containers. Ordinary Swing components can be seen as a logical area on AWT containers. They do not have a peer registered. All swing components added to a same top container share its AWT peer to acquire system resources, such as font, graphics etc. Swing has its own component data structure stored in JVM space. It manages drawing process, event dispatching and component layout totally by itself.

Resource Management

Because both AWT and SWT holds reference to native components, they must release them in a correct manner to avoid memory leaks and JVM crashes. AWT takes most of the resource management task to the system, relieving developers from tedious resource management. However this complicates the AWT implementation. Once it is implemented, developers has less opportunities to make errors and crash their applications.

SWT follows another way. In essence, SWT let the developers to manage those resources by themselves. There's a famous rule there. That is those who create the component should release it as well. Thus developers have to explicitly and carefully call the dispose method on every component or resource he has created. This greatly simplifies the SWT implementation model. But it puts the developers at the risk that they might easily crash their

applications due to incorrect coding.

Emulation difference

Both Swing and SWT uses emulation in their implementation. SWT emulate those components which are missing

from one platform. The difference is that SWT's emulation is much more like those of AWT Canvas. SWT has a Composite class which has a counterpart peer in the operating system. It gets all the resources it needs such as

graphics object, font or color from its own peer. It gets all the events directly from the operating systems process it. However, swing component does not have a counterpart peer. It is only logical area of the top container. The resources it acquires from itself are in fact borrowed from those top containers' peer. As to event, swing event is not the event generated from the underlying system. It is in fact a pseudo event which is generated when the top container processes AWT event. We'll detail it later in the event parts.

Graphical Layer Architecture

The other difference is that swing components have its own separate z-order system from AWT components. As I

mentioned above, swing components share a same peer with the top AWT container. Therefore, swing components have same z-order with the top container. SWT and AWT components each have a different z-order from the top container. So if AWT components and Swing components are mixed together, Swing components will probably be hidden by AWT components, because z-order values of AWT components are higher than the top container, while Swing components have the same z-order value with the top container. When operating system begin to update the UI, top container and swing components are always painted earlier than those of AWT. When they finished painting, AWT components will wipe out what swing has painted. So it is not encouraged to mix swing and AWT components together. If there are floating swing components such as menu, AWT component probably can hide

menus.

Layout Manager

Not all of the elements of the three are different. Layout manager is an exception. What is layout manager? When

developing a gui application, developers need to re-position or resize components when the container is resized. In traditional language, this is usually achieved by listening to resizing events. The code snippets usually scattered around and mess up the code. Java introduces the idea of wrapping layout codes together and name it Layout Manager. When a layout manager object is set to the container, it is automatically connected to resizing events. When resizing happens, layout method of the manger is called to re-position or reshape its children components.

AWT, SWT and Swing agree on this infrastructure. However every one has its own specific layout managers.

Because AWT and Swing share a common parent class java.awt.Component, therefore AWT and Swing layout

manger can work interchangeably.(To be continued ...)

AWT, SWT, Swing: Java GUI Clean Up (3)

Look And Feel

Native toolkits including SWT and AWT do not support Look And Feel mechanism. They bind their components to

operating systems, which have both pros and cons. One of the cons is that they cannot support pluggable Look And Feel. Handling the drawing process to operating system deprives of their ability to customize component look and

feel. This prevent them from providing Look And Feel mechanism. Look And Feel mechanism is becoming more and

more indispensable in GUI toolkit.

Swing has wonderful Look And Feel support. You can even change Swing application's look and feel dynamically.

This is an insurmountable task for AWT and SWT, since they handle their control entirely to operating system. I've heard many people complains about Sun on Swing design. They think why Swing can not be built on SWT like AWT. In fact, Look And Feel mechanism is one of reason why Swing should go in that direction. If Swing follows the way that wrapping existing components and emulating non-existing components, it cannot provide Look And Feel mechanism. Providing pluggable Look and Feel mechanism is an insurmountable task to native strategy.

Graphics and Fonts

Since Swing is an emulated system, its graphics tools is much more powerful than those of AWT and SWT. Swing bases its whole system on two fundamental components, one is Java 2D and the other is AWT. Java 2D is a powerful library in Java. It provides rich features of advanced image processing, color management, graphical drawing and filling, coordination system transmission and font manipulations. AWT and SWT only provides limited access to these features. Compared to Java 2D, they are comparably primitive and inferior.

JavaBeans Specification Conformity

Swing and AWT was designed with JavaBeans specification in mind. So their component classes conform to JavaBeans specification. However SWT does not quite conforms to this specification. For example, there's no empty-argument constructor in every component classes. Every component in SWT must has at least a single parameter constructor. This parameter is the parent of the components. That means whenever a component is created, it must be immediately added to a component tree. A component cannot exist without registered native peer. By this way, SWT wants the components created by programmer can be automatically released when dispose

methods of display is called.

More on Resource Management

SWT's strategy of component constructor can eliminate some possibility of memory leaks. AWT has the similar question about resource management. But it resolve the issues using a different way. When an AWT component is created, the counterpart peer will not immediately be added. When it is added to a component tree, but the tree is not visible yet, the peer will be still not created. Only when top container is set visible, will these peers be created. The method creating the peer generally is located in addNotify method. They generally call their parent's addNotify recursively until all of the peers on the component tree are created. When top container is dismissed by calling dispose method, a reverse method removeNotify will be called recursively to release these peers. By this way, AWT manage its resource without any interference from the developers.Event System

An event is the message sent to a GUI system, either from the outside or from the system itself, which requires certain action to be taken. These events include I/O interrupts from computer devices such as mouse or keyboard or network ports, and logical events triggered by GUI system, such as ActionEvent posted by a button.

Single-Threaded vs Multiple-Threaded

Dispatching events can follow two different models. One is called single-threaded dispatching model and the other

multiple-threaded dispatching model.

In single-threaded dispatching model, an event is pumped from the queue and processed in the same thread immediately. After the event being processed, next pending event in the queue is pumped again and continues the next round of cycle. In multiple-threaded dispatching model, the thread fetching the events from the queue launches another thread called task thread, and hand the event over to it for processing. The thread responsible for fetching the event does not wait for the end of the processing thread. It simply goes on to fetch next pending event

and dispatch it.

Event processing usually involves changing application data. While these data are often the source data that components display. Multiple-threaded dispatching can easily raise synchronization issues. It generates multiple event processing threads, which might interfere with each other. In a stable GUI system, component should be able to keep the view synchronized with the model. Because of the synchronization issue, multiple-threaded model requires developers to be more experienced in concurrent programing. For ordinary programmers, it is very easy to make synchronization errors. Therefore many GUI system don't use this model.

Single-threaded model provide natural synchronizations by enforcing sequential event processing. AWT, SWT and Swing all use this model to dispatch events. But single-threaded model also has its own issues. One of them is thread engrossment. Since all events are dispatched by a single thread, if one event processing last too long, it willhold back pending events from being processed. If there are PAINT event holding back, then the screen will appear

to be unresponsive. This usually make user feel that the software is slow. There are many such slow applications that are programmed by inexperienced developers. What they did is most probably cramming a listener method

with time-consuming tasks. Swing is especially prominent, since it is widely used. This has brought swing a bad reputation of slow and ugly. In fact, swing application can be very responsive if you knows to thread.

Thread Safety

The solution to the above issue is launching a separate worker thread to handle long-time processing, thus releasing the event dispatching thread to continue. Just like what multiple-threaded model does. But that also invites the synchronization issues that happen in multiple-threaded model. Many GUI toolkits often setup some innate mechanism to avoid this, for example, by a complex lock on a component tree. Developers don't have to worry about how to program to be safe. This kind of toolkit is called thread-safe. AWT is one of them.

However, it is often too complex to build such GUI system and usually it creates a lot overhead because of unnecessary synchronization. Therefore, Swing and SWT were designed to be thread unsafe. That means developers have to program carefully when they want to do multi-threading task. There is a little difference between SWT and Swing about runtime behavior towards thread safety. SWT always checks if the action modifying component takes place in the event dispatching thread. By this way, developers can find out the probable synchronization issues. Swing does not have. This is a shortage of Swing, which I think should not be so hard to

implement.

Event Dispatching Thread

AWT reads the primitive event from the operating systems and process them in java codes. AWT event dispatching thread is named as AWT-{OS}-Thread. This thread is launched implicitly by AWT system. When an AWT application launches, this thread starts in background, pumping and draining events from the operating systems. When logical events such button action is fired, it is passed over to action listeners registered on button. Developers can also listen to primitive events such as mouse, keyboard or paint event to write customized AWT components. This is generally done by extending AWT Canvas component. This component enables all of the available event happened on them, and by overriding the event processing method, you can implement a custom component.

However, in Swing, this is a different thread. Swing takes AWT events as the input of its event system. It gets AWT events and after some initial processing, generate a swing counterpart event and put it into its own event queue. Swing has own dispatching thread, usually named EventQueue-0. This thread pump swing events from the event queue, just as AWT does from the operating system. Then it dispatches this event to the target components. Usually an event is first post to the top container components. This event is then processed by the top container's dispatch methods. Then it may re-dispatching or re-targeting this event to a swing component, which in turn

continues the processing by its listeners.

For example, when a mouse moves over a Jbutton on a Jframe, an AWT event targeting Jframe is fired to the AWT-thread. The AWT-thread checks to see if it needs further processing. Then it wraps the event into a Swing MouseEvent object and enqueue it into the EventQueue. Upon receiving the MouseEvent, EventQueue-0 pumps this event out and dispatch it to Jframe by calling its.dispatching method. This method then translate MouseEvent and figure out the target Swing component. Here, the component is Jbutton. After that, it created a new MouseEvent with the new coordinations and event source re-target to the Jbutton. After that, it calls the jbutton.dispatch to continue dispatching. Jbutton.dispatch filters these event to a specific method and finally hit the point where it is

dispatched to specific mouse listener.

SWT is more akin to AWT. The only difference is that it requires the developers to explicitly write the event looping codes. However, the underneath implementation is different from that of AWT. Look at the code that SWT read and

dispatching events, it reminds you MFC code style.Event Listener

AWT, SWT and Swing have similar event listener models. They all use observer pattern, in which, components and

listeners are connected by adding listeners to components. This model forms a object-net model as shown in the following figure. When an event is fired and transmitted to the component by dispatching, the component call its

listeners to process this event. A listener can also further dispatching this event after processing, or it can event generate a new event and broadcast it to other nodes of the net. Basically there are two different way of broadcasting events. One is synchronously calling other listeners. The other is asynchronously posting this event to the queue, where it can get dispatched during next round of event dispatching.

Besides post method, Swing has some other way of dispatching asynchronous event. One of them is invokeLater from SwingUtilities or EventQueue. This method can wrap a Runnable object into a event and post it into the event queue. This ensures the run method of Runnable can be executed on the event dispatching thread, enabling thread-safety operation. In fact, Swing Timer and SwingWorker is implemented based on this mechanism. SWT also has this counterpart utilities which can asynchronously post events. Its invokeLater counterpart is

display.asyncExec which takes a Runnable object as parameter.

(To be continued ...)

AWT, SWT, Swing: Java GUI Clean Up (4)

Pros & Cons

To conclude the article, I'll give a list of pros & cons for each of them from a technical perspective.

AWT

AWT is a deprecated toolkit by Sun. However, it does has advantages. In many areas other than desktop environment such as mobile or embedded device, AWT has advantages.

1.Less memory consumption. Therefore it is suitable for developing GUI application which runs in an limited

environment, for example, mobile phone and so on.

2.Less startup time. Because AWT components are native components which are implemented by the

operating system, most of the binary codes can be loaded in advanced, for example, when operating

system starts. This can help to reduce AWT application startup time.

3.More responsive, Because native components are rendered by operating systems.

4.Standard GUI toolkit supported by JRE since java 1.x time. You don't have to install them separately. You

don't have to worry about platform differences.

5.Mature and stable. Seldom will it crash you applications and it just works.

However, everything has its own Achilles heel. Let's enumerate them:

1.Less component types. Table and tree are very important components missing. while table and tree are

very commonly used components in desktop applications.

2.Lacking rich component feature. Its buttons cannot have icon attached. This is clearly due to the fact, it is

design according to GCD principle.

3.No Look And Feel support. AWT is designed to use native components. Therefore, it depends on the system

to provide Look And Feel support. If there are no such support on the target platform, there's no way for

AWT to change its look and feel.4.Not extensible. AWT components are native components. The JVM instance of AWT classes are in fact only

references to the native components. The only extension point of AWT is its Canvas component, where you can create a custom component from scratch. However there's no way to extends and reuse an existing

AWT component.

SWT

SWT has the following advantages:

1.Rich component types. SWT provide a wide variety of components, from primitive components such as

Buttons and Labels to Tables and Trees.

2.Relative rich component feature. Although SWT is also designed following LCD principle, it has been re-

engineered to support more component features by emulations. So compared to AWT, it has relative more

component features.

3.Better response time. Due to the same reason as AWT, SWT components are wrapped native components,

which are rendered by the operating system. Operating system can usually optimize the rendering process.

It often store the GUI binaries as shared library, which reduces memory footprint, therefore improve the

response performance.

4.Less memory consumption. It is easy to understand this point, since operating system can take care of the

native components for applications.

As to disadvantages:

1.Not a standard library shipped by JRE. Therefore you have to bundle them together with your applications.

Also you have to build separate installers for every operating systems which you are to support.

2.Immature and unstable. SWT due to its many design defect, for example resource management, and

Windows-friendly design, is said to be unstable. It can perform very well on Windows. But on non-Windows operating systems, it is unstable and crashes very often. This is largely due to the fact that SWT leaves the resource management task to developers. However, not all developers can handle resource management

correctly.

3.Bad performance on non-Windows. As it is mentioned in No. 2, SWT is designed to accommodate Windows

API, which results in bad performance on non-Windows platforms. The end results include slow

performance, bad UI feelings, unstable or even memory leaks.

4.No Look And Feel support. The same reason as those of AWT.

5.Not extensible. The same reason as those AWT. In SWT, you can extend the component in a limited

manner. For example, you can listen to the PAINT event and add custom drawing on the component. But it is very limited, since you can only control part of drawing process. You can only make up after the

operating system draws the component. This is very bad for customization. Many modern applications

needs such ability to provide customized behavior.

Swing

Swing is the most powerful GUI toolkits. It has many advantages as well as disadvantages over the other two.

1.Rich component types. Swing provide very wide variety of standard components. These components are as

rich as those SWT. Besides these standard components, Swing has a lots of third part components, due to its extensible nature. There are many commercial and open source swing libraries on market after years of

development.

2.Rich component features. Not only swing combines all the feature on every platform, it can even provide

additional feature according to the platform the applications are running on. Swing component features are designed following GCD principle. And also swing components are very easy to be extended, therefore, swing components can usually provide much more functionalities than its SWT and AWT counterparts.

3.Good component API and model support. Swing is designed following MVC pattern, which is proved to be a

very successful design pattern. Its API are mature and well designed. After years of evolution, Swing

component APIs are becoming more and more powerful, flexible and extensible. Its API design is considered to be one of the most successful GUI API. They are more Object-Oriented, more flexible and

more extensible compared to SWT and AWT.

4.Excellent Look And Feel support. MVC design model enables Swing the ability to separate component view

from its data model. It has superior UI delegation which delegate UI rendering to UI classes. These classes are registered in an object, which represents a specific Look And Feel. There are now hundreds of LookAndFeel libraries available, which provides all kinds of different flavors of GUI styles. You can even

write your own LookAndFeel based on others work.

5.Standard GUI library. Swing as well as AWT is a standard library of JRE. Therefore, you don't have to ship

them separately with your application. You don't have to worry about platform incompatibility since they

are platform independent.

6.Stable and mature. Swing has been developed for more than 7 years. It is becoming more and more

mature and stable especially after Java 5. Since it is purely implemented in java, therefore, it has not such compatibility issues as those of SWT. Swing performs equally on every platforms. There are no drastically

performance difference between them.

7.Extensible and flexible. Swing is a library entirely implemented in Java space. Therefore, it controls

everything it needs. The architecture of Swing conforms to MVC pattern which exerts many of the

advantage of Java as an Object-Oriented languages. In fact, it provides several ways to extend the components. Let me briefly enumerate them. A. Extend existing components. B. Extending by composite components. C. Writing custom components using Jcomponent from scratch. D. Using renderer and editor mechanism to extend complex swing components such as Jlist, JcomboBox, Jtable, Jtree etc. E. Creating a new LookAndFeel either by extending existing LookAndFeel or writing a new one from scratch. F. Using LayeredPane, GlassPane or Drag and Drop mechanism to develop advanced components, such as docking

components, custom popup windows, custom menus etc.

8.Good overall performance. Swing has ever been mocked for its speed. However, with the development of

JRE, Swing is performing better and better now. Especially after Java 5, Swing's overall speed can compete

with any native widget systems.

A GUI speed can usually be measured in two aspects. One is response time, and the other is data

feeding time.