AWT, SWT & swing

OVERVIEW
Java GUI toolkit has always been a controversial topic. The same argument also occurs in other programming languages such as Smalltalk. In fact, there is a debate about languages unrelated to each platform. Java is currently the most widely used programming language.

This debate is between people who support simulated components (such as widgets and control, also known as counterfeit components) and local components (also known as native components in the following article, as a result, Java developers have formed two different camps, advocating the use of swing analog components and the use of SWT native components.

History
There are many stories about this debate on the Internet. You may have heard of the majority of them. One of them helps you clarify your mind. Let's start from here. Amy Fowler is an advocate of the swing camp.

Back in the 1990s s, there were three huge Smalltalk companies-IBM, PARC-place, and digitalk. In the early 1990s S, the market share of the three companies was roughly the same, and life was wonderful. Parc-place adopts emulated widgets (swing) design, while IBM and digitalk use native widgets ). Later IBM overwhelmed the other two, so they planned to merge them into one, assuming Parc-place digitalk. Then, when they tried to integrate their products into a project called Jigsaw, a war broke out, and the plan failed due to political reasons (developers have actually made it work ), the only reason is that the native and the counterfeited factions are dead.

Amy won the spiritual victory, but IBM won all their businesses, because the two companies did nothing except quarrel for a year. When the dust settles, PPD (PARC-place digitalk was renamed objectshare at the time, which is the same as the reason why Windscale was renamed Sellafield-Let people forget the previous disaster) the stock price fell from $60 to less than $1. They were delisted by NASDAQ because of fake reports, and then disappeared.

At that time, AWT had appeared. Sun has established a set of basic portable control classes that map to native widgets on different operating systems. At that time, AWT was full of vulnerabilities, far from being reliable, sun's coder needs to fix it. Amy was hired, and she promised to solve all the window component problems through a lightweight solution, so as to persuade Sun's management to make her the head of the GUI development department. Amy then hired all her old friends in Parc-place and asked them to develop swing.

At IBM, visualage for Java was originally written using Smalltalk (using native window components). When these tools are migrated to the Java code library, they need a set of window components. The developers on the IBM side are the ones who used to engage in Smalltalk. They are reluctant to use swing to build WebSphere Studio Tools for management. "Swing is a terrible and flawed monster". Therefore, a new project was started to port their Smalltalk native window components to Java. This toolset was later called SWT, and s started to be the abbreviation of simple, but then changed to the abbreviation of standard. This project was successfully applied to the released visualage Micro Edition product. They found that they used a method that may leave a memory vulnerability when reading the event queue in swing, and had to use their own loop to query the Windows event queue to correct this error. This led to their decision that SWT and AWT/swing cannot coexist. They put this toolkit in eclipse, a tool platform from Early Visual Age.

You should have a rough understanding of the history of the three from the above stories, especially SWT. Now you may think that the reason why IBM created SWT is reasonable, and swing should follow the SWT approach. This is one-sided. When you have a deep understanding of the nature of Java, you will find that it is not as simple as you think.

Prerequisites

What is the essence of Java that affects the design features of the toolset? Or, what are the prerequisites for the design of the Java GUI tool set?

The answer comes from Sun's commitment to Java: Write once and run anywhere ). This is the difference between Java and other languages. Before Java was created, the cross-platform performance of software was a nightmare for developers, especially those who wanted to provide support for multiple platforms. In today's life, internet is widely used. People in different corners of the world work on different platforms. Software providers provide support for different operating systems. Java's write-once-run-anywhere (Wora) commitment obviously reduces the burden on developers and greatly increases the productivity of software development.

However, to write cross-platform applications, you must use a standard library that supports platform independence. These standard libraries include language support, public use, network, I/O, and GUI tool sets. Therefore, when sun began designing a GUI tool set, the first task was to consider an API that is well designed and platform-independent. Both AWT and swing are carefully designed to ensure platform compatibility. SWT, on the contrary, is designed for a proprietary IDE Visual Age for Java instead of extensibility, windows has a high priority as the preferred runtime environment for this IDE. Swt api is similar to Windows, and generally it is not as scalable as swing. Although Steve northover, the father of SWT, argues that SWT is platform-independent, you can easily find many traces of Windows API.

Differences

GUI applications are a major type of software. Therefore, Java GUI Libraries should be standardized and integrated into the JRE platform. However, different operating systems have different GUI styles and component sets. Some components have similar views on the platform. These common components, such as buttons, labels, text fields, and single region, are called standard components. Different GUI tool sets provide different component sets. GUI tool sets always follow different principles to select Component Types and features for implementation. A tool set has two different elements: component type and feature.

Terms
First, let me illustrate two mathematical concepts: the maximum common number and the minimum common number. For example, three sets represent different operating systems. The intersection part is the maximum public approx. The merged part is the minimum public multiple.

Now let's take a look at the component types and features of the Java GUI tool set AWT, SWT, and swing.

AWT
The AWT component set follows the maximum public appointment principle, that is, AWT only has a public set of components on all platforms. Therefore, you cannot obtain advanced components such as tables or trees in AWT, because they are not supported on some platforms. The component features of AWT also follow this principle. It only improves the public features on the platform. For example, the AWT button cannot attach images, because on the Motif Platform, the button does not support images.

AWT cannot attract developers due to its inferior component set and features. It is not recommended by Sun to ensure backward compatibility and support for swing.

SWT

One of SWT's initial goals was to provide a richer set of components than AWT. It follows the principle of least common multiples to provide a union of components contained on each platform. The idea is that if a component is included on a platform, SWT will wrap it and call it using Java code and JNI. If a component does not exist on a certain platform, it will simulate the component by inheriting and drawing composite. A swt composite is similar to an AWT canvas. In this way, SWT provides a richer set of components than AWT. It is worth noting that SWT's JNI encapsulation is different from AWT, and its simulation is also different from swing.

In terms of component features, SWT is similar to AWT. It follows the principle of least common multiples. In earlier versions of SWT, The SWT button does not support image attachment for the same reason as AWT. In later versions, many missing features are supplemented in a simulated manner. However, there are still many features that cannot be purely simulated. SWT controls the components to the local operating system. It is difficult to expand. Only features such as case-based decoration can be achieved through simulated plotting. So strictly speaking, the component set and features of SWT components are not as rich as swing because they are difficult to expand.

Swing

Swing is the most powerful and flexible among the three. In terms of component type, it follows the principle of maximum common appointment. Swing can control all of its GUI systems with great scalability and flexibility. It can create almost all the components you can imagine. The only restriction is its AWT container. In swing, you cannot implement real transparent and irregular rectangular windows across platforms, because swing relies on AWT top-level containers such as applet, window, frame and dialog. In addition, swing implements almost all standard components on the platform.

Swing follows the principle of least common multiples in terms of component features. It has component features available on all platforms. In addition, you can inherit the existing swing components and add new features.

The above comparison is mainly at the API level. Let's move the focus of the comparison to the implementation details. The difference between swing and SWT/AWT is that swing is a pure Java implementation, while SWT and AWT are a mixture of Java and JNI. Of course, they all share the same goal and provide a cross-platform APIs. However, to achieve this, SWT and AWT have to sacrifice some components and features to provide a common APIs.

AWT
An AWT component is usually a component class that contains the reference of the peer interface type. This reference points to the local peer implementation. Java. AWT. label is used as an example. Its peer interface is labelpeer. Labelpeer is platform independent. On different platforms, AWT provides different peer classes to implement labelpeer. In Windows, the peer class is wlabelpeer, which calls JNI to implement the label function. These JNI methods are written in C or C ++. They are associated with a local label, and the actual behavior occurs here. As a whole, the AWT component provides a global public API for the application by the AWT component class and the AWT peer. A component class has nothing to do with its peer interface. The underlying peer classes and JNI code are platform-related.

SWT

SWT is also implemented using the JNI methodology. However, the details are different from those of AWT. SWT advocates are angry to hear that SWT and AWT are comparable. Steve northover, the father of SWT, complained about this.

Yes, they are different. Let's dive into the SWT code. In SWT, the only same part on each platform is the component interface, which is the Defined Signature of classes and methods. All the underlying code is platform-specific. SWT provides OS classes for each platform. This class uses JNI to encapsulate many local APIs. The SWT component class provides a meaningful function by sticking these JNI methods together.

For example, in windows, the selection of text fields is handled by a system call. This system call is implemented as a local method in the Windows OS class. Therefore, only one JNI call is used in the setselection method of text on Windows.

However, on motif, the selection of text fields contains two local calls. SWT implements two calls in the motif OS class. Therefore, the component class on Motif needs to be called twice for text selection.

Now you should be able to see the biggest difference between SWT and AWT. They use different peer-to-peer programming methods to eliminate platform differences. SWT uses Java code or Java peers implemented by JNI to merge system calls. AWT included the code in the Peer body, which made the situation more complicated. I personally think the SWT method is more wise.

Swing

By swing, everything becomes clear and straightforward. Besides the top-level containers, swing implementations do not depend on specific platforms. It manages all the control and resources. Swing requires event input to drive the system, as well as image processing, font and color from the top-layer AWT container. A common swing component can be considered as a logical area of an AWT container. They do not register peers. All swing components added to the same top-level container share their AWT peers to obtain system resources, such as fonts and graphic processing. Swing stores the component's own data structure in the JVM space. It manages drawing processing, event distribution, and component layout by itself.

Since both AWT and SWT hold references to local components, they must release these references in the correct way to avoid Memory leakage and JVM crash. AWT handed over the vast majority of resource management tasks to the system, saving developers from monotonous resource management. However, this complicate the implementation of AWT. Once implemented, developers rarely have the opportunity to make mistakes and crash their programs.

SWT uses another method. In general, SWT allows developers to manage resources themselves. One of its famous rules is: who created and released. Therefore, the developer must call the dispose method with caution to release each component and resource created by him. This simplifies the implementation model of SWT, but puts developers at the risk of program crash caused by incorrect coding.

Differences between simulation methods

Swing and SWT both use simulations in their implementations. SWT only simulates the missing components on the platform. The difference is that the simulation of SWT is more like the simulation of the canvas Implementation of AWT. The SWT composite class has its own counterparts in the operating system. It obtains all the objects, fonts, and colors required for resource processing from its own peer. It obtains and processes all events from the operating system. However, the swing component does not have an equivalent in the operating system. It is only a logical area in a top-layer container. In fact, it borrows resources from the peer body of the top-layer container. Swing events are not events generated by the underlying system. They are actually pseudo events generated when the top-level container processes AWT events. We will introduce it in detail in the event section later.

Graph Layer Structure
Another difference is that the Z-order system of the swing component comes from the AWT component. As mentioned above, the swing component shares a peer with the top-layer AWT container. Therefore, the swing component also has the same Z-order as the top-level container. SWT and AWT components are different from the Z-Order of the top-level container, which is usually higher than the top-level container. Therefore, if the AWT component and the swing component are mixed together, the swing component may be hidden by the AWT component. When the operating system starts to update the UI, the top-layer container and swing component are always drawn prior to the AWT component. When they are drawn, the AWT component overwrites the areas that swing may have drawn. Therefore, mixed use of swing and AWT components is not recommended. If there is a floating swing component such as a menu, the AWT component may overwrite the menu.

Layout manager

Not all of the three are different. The layout manager is an exception. Develop a GUI application. When the container size changes, the component needs to be relocated or changed. In traditional programming languages, this is achieved by listening for events with changed sizes. The corresponding fragments are scattered in various corners of the source code to reduce the readability of the program. Java introduces the idea of encapsulating layout code, which is called layout manager. When the layout manager object is set to a container, it automatically handles the event of size change. When the size changes, the manager's layout method is called to relocate child components or adjust their shapes.

AWT, SWT, and swing are organized in this way, and they all have their own unique layout managers. Since AWT and swing share a common superclass of Java. AWT. component, their layout manager can be used alternately.

Look and Feel

Local tool sets, including SWT and AWT, do not support the look and feel mechanism. They bind components to the operating system, which has its advantages and disadvantages. One disadvantage is that they do not support pluggable look and feel. Rendering is done by the operating system to deprive them of the ability to implement the look and feel custom components, which makes them unable to provide such a mechanism. The look and feel mechanism is increasingly becoming an indispensable part of the GUI tool set.

Swing has good support for look and feel. You can even dynamically change the look and feel of swing applications. Given that AWT and SWT completely control components to the operating system, this is a task they cannot go beyond. I have heard many people complain about Sun's design on swing. Why do they think swing does not follow the AWT idea as SWT does? In fact, the look and feel mechanism is one of the reasons why swing is in this direction. If swing wraps existing components and simulates the routes of nonexistent components, it cannot provide the look and feel mechanism. Because the "look and feel" mechanism is a task that cannot be completed by a local policy.

Graphics and fonts graphics and Fonts
Swing, as a bionic system, is much more powerful than AWT and SWT in its graphic tool set. Swing is based on two basic component groups in its own system: Java 2D and AWT. Java 2D is a powerful class library in Java. It provides rich features for advanced image processing, color management, drawing and filling, coordinate system transformation, and font generation. In contrast, AWT and AWT only provide limited access to these features, which are relatively primitive and low-level.

JavaBeans specification conformity ans specification consistency
Swing and AWT have been designed to comply with the ANS ans specification, and their component classes are consistent with those of the JavaBeans specification. However, SWT does not follow this rule well. For example, there is no constructor without parameters in the SWT component class. Each component must have at least one single-parameter constructor. This parameter is referenced by the parent component. This means that the component is directly added to a component tree whenever it is created. A component cannot exist without a registered local peer. In this way, SWT can automatically release components created by programmers when the display dispose method is called.

More on resource management more on resource management
SWT's component constructor policy can eliminate the possibility of Memory leakage. AWT has similar problems in resource management. But it uses different solutions. When an AWT component is created, the corresponding peer is not created immediately. Even if it is added to a component tree that is invisible, the peer object will not be created. Only when the top-layer container is set to visible can these peers be created. The method for creating a peering body is usually in addpolicy, which recursively calls the addpolicy of the parent component until the peers on the entire component tree are created. When the top-layer container is destroyed by the dispose method, a corresponding method removenotify will be recursively called to release these peers. In this way, AWT manages its resources without the developer's intervention.

Event System
An event requires that a specific action be executed and sent to the GUI system as a message by the outside world or the system itself. These events include I/O interruptions from computer devices such as mouse and keyboard, and network ports, as well as triggering of GUI system logic events, such as actionevent events of a button.

Single-threaded vs multiple-threaded single-thread vs multi-thread
Event distribution follows two different models. Single-thread distribution model and multi-thread distribution model.

In the single-thread distribution model, an event is extracted from the queue and processed immediately in the same thread. After the event is processed, the next event that follows is extracted and the next cycle continues. In the multi-thread distribution model, start another thread called the task thread from the thread that obtains the event from the queue and hand over the event to it for processing. The thread that obtains the event does not wait until the processing thread ends. It simply gets the next thread and distributes it.

Event processing usually involves data changes in applications. The data is often displayed by components. Multi-threaded distribution is prone to synchronization issues, which generate multiple event processing threads that may interfere with each other. In a stable GUI system, components should be able to synchronize views with models. Due to synchronization problems, multithreading models require developers to have more experience in concurrent programming. For common programmers, it is easy to cause synchronization errors. Therefore, many GUI systems do not use this model.

The single-threaded model is serialized by force events to provide actual synchronization. AWT, SWT, and swing both use this model to distribute events. But the single-threaded model also has its own problems. One of them is thread focus. Since all events are distributed in one thread, if one event takes too long to be processed, extraction and execution of the next event will be delayed. If a paint event is delayed, the screen will become unresponsive. This often makes the user feel that the software is slow. Many of these inefficient programs are caused by lack of developer experience. Their approach is to populate time-consuming tasks with the listener method. This incorrect programming method is especially prominent because it is widely used in swing, which is also one of the origins of its slow and ugly bad reputation. In fact, if you know how to use threads, swing applications can show a high degree of response.

Thread Safety thread security

The solution to the above problem is to start a separate worker thread to complete time-consuming processing, so that the event distribution thread can be released for processing to continue operation. As in the multi-threaded model, however, this will also introduce synchronization problems in the multi-threaded model. Many GUI tool sets have their own inherent mechanisms to solve this problem, for example, the combination lock on the component tree. Developers do not need to worry about how to program securely. Such a tool set is thread-safe. AWT is one of them.

However, the establishment of such a GUI system is too responsible and overhead due to unnecessary synchronization. Therefore, swing and SWT are designed to be non-thread-safe, which means developers must implement their multi-threaded tasks with caution. There is a small difference between SWT and swing in thread security behavior during runtime. SWT always checks whether operations to change components are executed on the event distribution thread. In this way, developers can find synchronization problems. Unlike swing, this is an unknown beginning of swing, which is not difficult to implement.

Event dispatching thread event distribution thread

AWT reads basic events in the operating system and processes them in Java code. The AWT event distribution thread is named? AWT-{OS}-thread. This thread is implicitly started by the AWT system. When the AWT application starts, this thread starts behind the scenes and extracts and removes events from the operating system. When a logical event such as a button action is triggered, it is passed to the operation listener registered on the button. Developers can also write the mouse, keyboard, and event listener for the AWT component. This is usually done by extending the AWT canvas component. This component supports all provided events, and you can rewrite the event processing method to implement a custom component.

However, in swing, this is a different thread. Swing uses AWT events as an input to its own event system. It obtains the AWT event and performs initialization to generate a corresponding swing event and put it on its own event queue. Swing also has its own event distribution thread, typically named EventQueue-0. This thread extracts swing events from the event queue, just as AWT extracts from the operating system. It then delivers the event to the target component. Generally, events are first distributed to the top-level container of the component and then processed by the dispatch method of the top-level container. It may be re-distributed or redirected to a swing component, the listener will continue to process the process.

For example, when a mouse moves over a jbutton or jframe, an AWT event pointing to the jframe is triggered on the AWT thread. The AWT thread checks whether it needs more processing, then packs it into a swing mouseevent object, and adds it to the eventqueue queue. When the mouseevent event is obtained, the EventQueue-0 extracts the event and determines the target swing component. Here, this component is jbutton. Then it generates a new mouseevent containing the Relative Coordinate Position and event source to redirect to this jbutton, and then calls the dispatch of this jbutton to continue distribution. The dispatch filtering event of jbutton is used to filter the clicks that are distributed by the mouse listener on a specific method.

SWT is more similar to AWT. The only difference is that it requires developers to explicitly write the event loop code. However, the underlying implementation details are different from those of AWT. Let's take a look at the reading and distributing Event code of SWT. It reminds you of the Code style of MFC.

Event listener event listener
AWT, SWT, and swing have similar event listener models. They all use the observer mode. The connection between the component and the listener is to add the listener to the component, which forms an object network model. When an event is triggered and distributed to the component, the component calls its listener to process the event. A listener can also distribute events to subsequent processes, or generate a new event and broadcast it to other nodes in the network. There are basically two different broadcast events. One is synchronous call listener. The other is to asynchronously send events back to the queue, which will be distributed in the next round of event distribution.

In addition to sending messages directly to the queue, swing also has some other methods for distributing asynchronous events. One of them is the invokelater that calls swingutilities or eventqueue. This method wraps a runnable object into the event and sends it to the event queue. This ensures that the runnable run method can be executed on the event distribution thread, ensuring thread security. In fact, swing's swingworker is implemented based on this mechanism. SWT can also send asynchronous events. The corresponding method of invokelater is display. asyncexec, which uses a runnable object as the parameter.

I have provided a list of their advantages and disadvantages at a technical level to end this article.

AWT
AWT is not recommended for sun. However, it has its own advantages in many non-desktop environments, such as mobile or embedded devices.
Less memory. It is suitable for the development of GUI programs running in a limited environment.

1. Fewer startup events. The AWT component is implemented locally by the operating system. Most of the binary code has been pre-loaded when the system is started, reducing its startup events.

2. Better response. Because local components are rendered by the operating system.

3. In the era of Java 1.x, it is a set of standard GUI tools supported by JRE. You don't have to install it separately, and you don't have to worry about platform differences.

4. Mature and stable. It works and rarely crashes your program.

However, things all have their bad side. Let's count it.

1. Fewer component types. Important components such as tables and trees are missing. They are widely used in desktop applications.

2. Lack of rich component features. The button does not support image attachment. This is obviously caused by the design principles it follows.

3. Look and Feel are not supported. AWT is designed to use local components. Therefore, it relies on the system to provide support for look and feel. If the target system does not support this feature, AWT cannot change its look and feel.

4. No scalability. AWT components are local components. The AWT instance in JVM actually only contains references to local components. The only extension point is the canvas component of AWT. You can create custom components from scratch. However, an existing AWT component cannot be inherited or reused.

SWT
SWT has the following advantages:

1. Rich component types. SWT provides a wide range of components, from basic components such as buttons and labels to advanced tables and trees.

2. relatively rich component features. Although SWT follows the principle of maximum public multiples, it re-designs support for more component features in a simulated manner. Therefore, compared with AWT, it has rich component features.

3. faster response time. For the same reason as AWT, The SWT component encapsulates local components and is rendered by the operating system. The operating system usually optimizes rendering and saves the GUI binary code as a standard library, reducing memory usage and improving response performance.

4. Less memory consumption. Since the operating system provides Optimization for local components, this is easy to understand.

Disadvantages:

1. It is not in the JRE standard library. Therefore, you must bind it with your program and create a separate installer for each operating system you want to support.

2. Not mature and stable enough. SWT is considered unstable due to its design defects, such as resource management and Windows friendliness. It works well on windows, but on other operating systems, it is often unstable and prone to crashes. This is largely because it manages resources to developers, and not all developers can handle this correctly.

3. Poor performance on non-Windows platforms. As mentioned at, SWT is designed to coordinate with Windows APIs, leading to performance problems on non-Windows platforms, poor UI senses, instability, and even Memory leakage.

4. No support for look and feel. The same reason as AWT.

5. It cannot be extended because it is the same as AWT. In SWT, you can expand a component in a limited way, for example, listening to the paint event and adding a custom drawing to the component, but since you can only control part of the painting process, this is very limited. You can only add components after the operating system draws them. This does not support customization. Many applications have high requirements on user-defined behaviors.

Swing
Swing is the most powerful GUI tool set among the three. It has the same advantages and disadvantages as the other two.

1. Rich component types. Swing provides a wide range of standard components. These components are as rich as SWT. Based on its excellent scalability, in addition to standard components, swing also provides a large number of third-party components. Many commercial or open-source swing component libraries can be easily obtained after years of development.

2. Rich component features. Swing not only includes features on all platforms, but also supports adding additional features based on the platform where the program runs. The features of swing components follow specific principles and are easy to expand. Therefore, they provide more functions than SWT and AWT.

3. Good component API Model support. Swing follows the MVC pattern, which is a very successful design pattern. Its APIs are mature and well designed. After years of evolution, the swing component APIs has become increasingly powerful, flexible, and scalable. Its API design is considered to be one of the most successful GUI APIs. Compared with SWT and AWT, it is more object-oriented and flexible and scalable.

4. Excellent support for look and feel. The MVC design model allows swing to separate component views from its data models. It has an advanced UI delegate to delegate UI rendering to the UI class. These classes are registered to an object that shows a specific look and feel. There are already hundreds of look and feel to improve a variety of GUI styles. You can even write the look and feel component based on the results of others.

5. Standard GUI library. Swing, like AWT, is the standard library in JRE. Therefore, you do not have to distribute them separately with your application. They are platform-independent, so you don't have to worry about platform compatibility.

6. Mature and stable. Swing has been developed for seven years. After Java 5, it became more mature and stable. Because it is implemented in pure Java, there will be no compatibility issues with SWT. Swing has the same performance on each platform without significant performance differences.

7. scalability and flexibility. Swing is fully implemented in Java space. It can control what it needs together. Swing's MVC-based structure enables it to take advantage of Java as an object-oriented language. It provides many extension component methods. Let's list:

A. inherit existing components;
B. Extension by means of composite components.
C. Use jcomponent to write custom components from scratch;
D. Use the Renderer and editor mechanisms to extend the copied swing components, such as jlist, jcombobox, jtable, and jtree;
E. Create a new look and feel based on the existing look and feel or from scratch;
F. Use layeredpane, glasspane, or drag-and-drop mechanisms to develop advanced components, such as floating fixed components, custom pop-up windows, and custom menus.

8. Excellent overall performance. Swing speed is a bit of criticism. However, with the development of JRE, swing's performance has now greatly improved. Especially after Java 5, the overall speed of swing can be close to that of the local small control system.

The speed of a GUI is always measured in two ways: response time and data feedback time.

Response events refer to the time from the event task to the time when the component updates the UI. For example, click a button, drag a component, and change a multi-label panel. In this respect, the local component can always have better response than the simulated component. AWT and SWT usually show better response time than swing. However, this is not always the case. This depends on the operating system. If the local component is not well implemented, the result is the opposite. For example, Windows has developed a good GUI library, while Linux platforms are usually far behind. SWT may be better than swing in windows, but worse than swing in Linux. That is to say, the performance of AWT/SWT depends on the underlying platform. With the development of JRE, swing's response performance can be greatly improved with JVM optimization, better implementation methods, and graphic hardware acceleration. On Windows, swing of Java 6 can rival the performance of SWT. In non-Windows environments, swing can show better response times.

Data delivery time refers to the time required to pass application data to the UI component. For example, a student management system requires that student information be loaded from the database and displayed in a table. The data transfer time from memory to table components is called the data transfer time. In this respect, swing is generally better than the other two. It may not be obvious when the data volume is small. However, this is obvious when a large amount of data is transferred to a table. To understand this, we remind you that the JVM and local operating systems are two separate runtime environments. JNI calls take longer than a common Java call because they occur in two environments by leaps and bounds. Generally, this includes two processes. One is to convert the Java data structure to the local data structure, and the other is to convert the local data structure when the method is returned to the Java object. Other performance overhead are temporarily ignored. When a large array of data is transmitted from a local component, a large number of repeated JNI calls will greatly degrade the performance.

Another advantage of swing is that it has many component models to improve the delivery performance. For example, tablemodel is mapped to an array in two dimensions. In this way, you do not even need to convert the data in the swing component. Swing directly displays application data on the screen, saving the time spent on data conversion.

Swing also has the following shortcomings:

More memory consumption than AWT and SWT. Swing implements all its own components. Therefore, it loads a large number of classes at runtime. Some other problems come from the creation of small variable objects, such as rectangle and point. These objects cannot be reused Based on synchronization considerations. Java creates an object on the stack. Small objects usually consume additional heap space. Many small objects are more difficult to be effectively recycled than large objects. Therefore, swing applications cannot recycle large and small objects in a timely manner. In this case, the performance may decline.

More startup times. Now JVM is much faster. Many people even threatened that it could be comparable to the implementation of C ++. However, most Java applications still look slow. In fact, many Java performance problems come from the class loader System. This is an I/O operation, which can significantly reduce the speed of Java applications. Maybe this is a problem for every dynamic link system. Swing usually contains thousands of swing classes. Before a swing application can display its main window, it loads much more classes than AWT or SWT. This seriously reduces the start time of swing. This problem may be better if the swing class is pre-loaded using the shared system library.

The above comparison is a technical summary. Other factors also affect your choice of a toolset. For example, documents, support, learning curves, and communities, but since we focus on the technical layer, we will not talk too much here.

 

From: http://dolive.javaeye.com/blog/202758