Differences in the principles and efficiency of the three GUI technologies in Java: AWT, swing, and SWT

Minehe original
I read a post on the Java GUI, so I wrote an article to illustrate the advantages and disadvantages of various GUI technologies.
In the Java World, the three most well-known GUI Libraries are:
1. AWT (Abstract Window Toolkit) Abstract Window tool package library, which is included in all Java sdks
2. Swing advanced graphics library, included in Java2 SDK
3. The standard Windows component library of SWT (Standard Widget Toolkit) from the IBM Eclipse open-source project is not included in JDK and needs to be downloaded separately from eclipse

I. AWT principle: small but simple GUI system
AWT appears in Java 1.x and is a built-in library for window-oriented applications in the early stage of Java. AWT uses a peer-to-peer design model. For more information about its structural relationships, see.

From this class relationship diagram, we can easily see the technical implementation of AWT and the peer design pattern. In the figure, the yellow class is the class in the Java. AWT package, the light gray part is the Java Virtual Machine part, and the dark gray part is the Windows platform.
AWT focuses on peer-to-peer design. The so-called peer-to-peer design mode is to direct the AWT control to a similar or equivalent control on the running platform. The button class corresponds to the dark gray windows standard button function.
The peer-to-peer mode is used to establish an interaction between two controls, and acts as a bond between the Java Virtual Machine and the virtual machine-GDI interface (in Windows as an example ). Therefore, we can see that AWT needs to control graphics and events through common Java technologies first, and then the Java Virtual Machine transmits requests to specific platform graphics and control interfaces for interaction.
The efficiency of the peer-to-peer mode is not very high, because AWT completes an operation through the Virtual Machine and Virtual Machine-GDI. The more level systems that pass through, the slower the speed and efficiency. In addition, peer-to-peer mode has a fatal weakness: Poor portability!
This is the main reason why Sun tempted us to leave AWT with swing. Since it is in the peer-to-peer mode, AWT must use the intersection of the graphic interface functions of all graphic operating systems, because there is only one set of AWT interfaces, so to ensure portability, you can only use the least features supported by all systems. As a result, we often hear people complain that AWT features are too few, and images are too ugly. this is a sacrifice to ensure portability.

II. The birth of the huge beast-swing

Beginning with Java2, Java 1.2, sun began to provide a new GUI interface system-swing in JDK. All Java enthusiasts are devoted to swing research and infatuation. With the emergence of a large number of IDES and programs using swing as the interface technology, everyone soon realized the problem of swing.
Some people think that swing is a lightweight GUI system. No matter what the official saying goes, no Java programmer will think that swing is lightweight. On the contrary, swing is a very huge GUI library, this is already the consensus of the Java Community.
Some underlying classes of swing use a few basic classes, such as component, iner, and window of AWT. It is estimated that the reason is to maintain compatibility with AWT and facilitate code porting to swing.
The following is the class relationship diagram of swing:

The Chrysanthemum yellow class is a swing package class. By comparing the swing chart and the AWT chart, we can find that the dark gray windows control class in the AWT system has been removed from the swing chart. Swing no longer follows the peer-to-peer mode to implement GUI.
This is one of swing's core ideas. Swing is fully implemented based on Java self-drawn graphics. Therefore, the swing interface does not look similar to Windows, especially the style of the window control (although we can also use a skin swap to simulate the Windows interface ).
Therefore, it is clear that swing is a high-level GUI system, rather than a system that is closer to the operating platform technology as AWT.We still use the button and Panel as an example. The relationship in the figure shows that the class inheritance relationship of swing is much more complex than that of AWT, in addition, most swing classes have passed through the intermediate transfer class-jcomponent. The common jframe is a different path, inherited from the AWT window.
This structural relationship determines the size and complexity of swing. Many beginners cannot understand the swing mode and structure.
The controls in swing are drawn using the Java graphical function, rather than a specific control corresponding to the platform. All the swing controls we use are drawn directly or indirectly using graphics. The biggest benefit of this implementation method is that it is very flexible. We just need to use graphics to draw the desired control directly.
Sun uses this method to add rich interface interaction functions without sacrificing portability.

But the disadvantage is also obvious: swing's speed and efficiency are the slowest in all gui systems.

JBuilder and netbeans IDE are both pure swing interfaces. You can start them and perform operations, such as dragging the window and try to understand what I'm talking about.
The reason for this result is:
1. Swing's class hierarchy is too deep. A jframe goes through a class inheritance relationship of Layer 4. If it is added to the internal implementation of the graphics function of the virtual machine, there will be a 6-layer switching relationship, every inheritance and transfer will consume system resources and speed loss. (Excessive inheritance will reduce the system speed, because the operation subclass usually uses the base class to point to complete general operations)
2. Swing is based on the self-drawn graphics technology. To maintain portability, Java cannot use hardware acceleration and platform features to speed up graphic operations. Therefore, Java's graphics technology is a "high-level" graphics technology, as if we use Windows GDI for animation, of course, the speed will be very slow.
3. New Dawn-SWT

It should be said that Java programmers who have some experience know that many people complain about low swing efficiency. The Eclipse open source project sponsored by IBM has developed an alternative GUI system-SWT.
SWT is a very unique technology. Its core idea is exactly the same as that of DirectX on Windows. Maybe SWT programmers really learn the secrets of DirectX success.
The following is a class Relation Diagram of SWT technical principles:

We can see that the SWT class relationship is very direct and easy to understand. It is a bit like Delphi's API interface idea (this is what I casually play, it has nothing to do with Delphi ). The most important thing is the core idea of SWT: The implementation of SWT functions is completely built on JNI-based and directly called and encapsulated on the operating platform.
We can see that the SWT function is not operated by any Java virtual machine, but is directly called by Windows GDI and Shell functions, which is completed through JNI method call.
Some people will say that SWT has broken Java's idea of porting, but the wide range of Eclipse's popularity just proves that SWT has not hindered portability, instead, it improves the usage and expectation of various operating systems for the Java GUI. It cannot be said that the Eclipse project team is full of wisdom.
In eclipse, under the SWT directory of the plugin directory, you can find a DLL dynamic library file, which is the JNI method call library.
The eclipse Interface Based on SWT technology is not only fast, efficient, but also more beautiful than swing. This is the effect of calling the encapsulation directly.
Let's look at the source code of SWT to better understand why SWT is so popular and why SWT is as fast as flying. Below is a small piece of code extracted from the button class:

Code: int callWindowProc (int msg, int wParam, int lParam) {  if (handle == 0) return 0;  return OS.CallWindowProc (ButtonProc, handle, msg, wParam, lParam); } int windowProc () {  return ButtonProc; } LRESULT wmDrawChild (int wParam, int lParam) {  if ((style & SWT.ARROW) == 0) return super.wmDrawChild (wParam, lParam);  DRAWITEMSTRUCT struct = new DRAWITEMSTRUCT ();  OS.MoveMemory (struct, lParam, DRAWITEMSTRUCT.sizeof);  int uState = OS.DFCS_SCROLLLEFT;  switch (style & (SWT.UP | SWT.DOWN | SWT.LEFT | SWT.RIGHT)) {    case SWT.UP: uState = OS.DFCS_SCROLLUP; break;    case SWT.DOWN: uState = OS.DFCS_SCROLLDOWN; break;    case SWT.LEFT: uState = OS.DFCS_SCROLLLEFT; break;    case SWT.RIGHT: uState = OS.DFCS_SCROLLRIGHT; break;  }  if (!getEnabled ()) uState |= OS.DFCS_INACTIVE;  if ((style & SWT.FLAT) == SWT.FLAT) uState |= OS.DFCS_FLAT;  if ((struct.itemState & OS.ODS_SELECTED) != 0) uState |= OS.DFCS_PUSHED;  RECT rect = new RECT ();  OS.SetRect (rect, struct.left, struct.top, struct.right, struct.bottom);  OS.DrawFrameControl (struct.hDC, rect, OS.DFC_SCROLL, uState);  return null; }

I think anyone with a bit of Windows programming knowledge will be surprised by the SWT methods and practices. What do lresult and windowproc do? I don't want to say much. The first time I saw SWT code, I was surprised to open my mouth. I really couldn't imagine that the SWT project team dared to integrate Java technology with the Windows platform so closely (of course, the Linux platform version is also closely integrated ). I found a class named tray in SWT. I guess what it is doing? Tray allows you to display a taskbar icon in a Java program, which is extremely dizzy!
I don't want to introduce SWT any more. You must be very excited. From SWT, javagui does not necessarily mean slow, low-efficiency, and weak functions, as well as high-speed Windows programs, java programs can also possess them, which is the value of SWT.
More importantly, SWT breaks the long-standing misunderstanding about portability. It seems that portability can only be used with fewer and fewer features. We can also use JNI to embrace the Java World. I think, in the future, the interface will not only use the JNI method, but many of our Java ideas may change quietly. Maybe one day our Java code can run as fast as VB, this change in ideology is the value of SWT.
I don't know about the final outcome of swing, but I know that I prefer lightweight and fast SWT, so I have another option for your program.