分类: Java
2011-03-08 15:00:35
To conclude the article, I'll give a list of pros & cons for each of them from a technical perspective.
AWTAWT 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.
Less memory consumption. Therefore it is suitable for developing GUI application which runs in an limited environment, for example, mobile phone and so on.
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.
More responsive, Because native components are rendered by operating systems.
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.
Mature and stable. Seldom will it crash you applications and it just works.
However, everything has its own Achilles heel. Let's enumerate them:
Less component types. Table and tree are very important components missing. while table and tree are very commonly used components in desktop applications.
Lacking rich component feature. Its buttons cannot have icon attached. This is clearly due to the fact, it is design according to GCD principle.
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.
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 has the following advantages:
Rich component types. SWT provide a wide variety of components, from primitive components such as Buttons and Labels to Tables and Trees.
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.
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.
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:
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.
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.
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.
No Look And Feel support. The same reason as those of AWT.
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 is the most powerful GUI toolkits. It has many advantages as well as disadvantages over the other two.
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.
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.
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.
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.
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.
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.
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.
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.
Response time means the period between the time an event takes place and the time the component updates its UI. For example pressing a button, dragging a component, changing a tabbed pane selection, etc. In this aspect, native components usually have better response time than an emulated one. AWT and SWT components usually have better response time than those of Swings. However this is not always true. It depends on the operating systems. If native components are not implemented well on that platform, it might be the contrary. For example, Windows usually have their GUI library polished very well, while Linux platforms usually don't do well. Therefore, SWT can perform better than Swing on Windows, but might perform worse than Swing on Linux. In one word, the performance of AWT/SWT depends the underlying platforms. With the development of JRE, Swing response performance has been greatly enhanced due to JVM optimization, better swing implementation, graphics hardware acceleration etc. Swing in Java 6 can even compete with SWT on Windows. On non-Windows, Swing has much better response time than SWT.
Data feeding time means the time that is taken to transmit application data to UI components. For example, a student management software is asked to load some students information from the database and display them on a table. The time spent on transmitting those students from the memory to the table components is called feeding time. In this aspect, Swing usually performs better than the other two. It is not so obvious when there are not much data to be fed. But if there are tremendous data to be fed into the table, it is becoming more and more noticeable. Why? To understand it, you have to be reminded that JVM and native operating systems are two separate running environment. JNI call made by java program usually consumes much more time than ordinary java call. It is obvious that JNI call is an action that spans two different systems. When a JNI invocation happens, it usually involves two process. One is that Java data structure is translated into native system structure. And second, when a method returns, the returned values should also be translated into java objects. Not to mention other performance costs. When a large bound array of data are fed to native component, there will be large amount of JNI call which can drastically slow down the performance.
And anther swing advantage is that it has many component models which can speed up the feeding performance greatly. For example tablemodel can be mapped to a two dimension array. In such case, there is even no data transmission happened in Swing components. Swing table directly displays the application data to the screen, greatly eliminating the time spent on data transmission.
As to Swing's disadvantages:
More memory consumption than AWT and SWT. Swing has all its components implemented by itself. Therefore, it has much more classes to be loaded in runtime. There are some other issues such as small immutable objects creation, such as Rectangle, Point etc, these objects usually cannot be re-used due to synchronization consideration. Java creates all the objects on the heap. And small objects can often waste heap space. These small objects garbages can not be collected efficiently compared to large objects. Therefore, Swing application often creates a lots of small objects which can not be collected in time. More often it can result in performance degradation. In Java 7, there will be a new JVM feature to added, namely memory escape analysis and stack allocation, which can help to optimize memory allocation and deallocation performance. This surely will enhance the speed of swing, which is now plagued by small immutable objects creation and collection. If you are interested in memory escape analysis, read the entry from the wikipedia:
More application startup time. Now JVM is fast enough. Some people even claimed that java platform can even compete with some C++ implementation. But still there are some java applications which seem to be very slow. In fact, many java performance issues are caused by class loading. Class loading is an I/O operation which can greatly slow down java applications. Perhaps this is the issue that every dynamic linking system must faces. Swing application usually involves thousands of thousand Swing classes. Before Swing application can show its main window, it has loaded much more classes than AWT and SWT applications. This can greatly increase Swing application startup time. If Swing classes are pre-loaded as shared system libraries, this issue can easily be resolved.
The above comparison is mainly conducted in technical perspective. There are many other terms which should be considered when you choose a toolkit. For example, documentation, support, learning curves and community etc. But since we are focusing their technical sides, we shall not detail them here.
(End)