Java Swing AWT Lightweight build and heavyweight components

The lightweight component first appears in the AWT1.1 version. AWT initially includes only the weight components associated with the local peer component, which are drawn in their own local opaque windows. In contrast, swing components are almost always lightweight components, with no local peers compared to weight components, unlike weight components that are drawn in their own local opaque forms, and lightweight components drawn in the windows of their weight components.
Because lightweight components are not drawn in local opaque windows, they can have a transparent background. A transparent background makes the lightweight component that is displayed can be rectangular, although all components (weight or lightweight) have a rectangular border. Swing is implemented in 100% pure Java, and swing components are lightweight (light-weight) components implemented in Java, with no local code and no reliance on operating system support, which is the biggest difference from AWT components. Because AWT components are implemented through Peer-to-peer classes (Peer) related to specific platforms, swing is more practical than AWT components. Swing is consistent on different platforms and has the ability to provide other features that are not supported by the local window system. In AWT components, the peer class that controls the appearance of the component is associated with a specific platform, making AWT components always have a native-related look. Swing makes it possible for a program to look different when it runs on one platform. Users can choose their own habits of appearance.
In the javax.swing package, two types of components are defined: Top-level containers (Jframe,japplet,jdialog and JWindow), and lightweight components. Swing components are both direct subclasses and indirect subclasses of the container class of AWT. Swing components are almost always lightweight components, with the exception of top-level containers: forms, small applications, Windows, and dialog boxes. Because the lightweight component is drawn in the window of its container, rather than in its own window, the lightweight component must eventually be included in a weight container. Therefore, swing forms, small applications, Windows, and dialog boxes must all be weight components to provide a window in which you can draw a swing lightweight component.

-----------------------

Attachment: In order to quickly market and maintain a local interface style, it produces an architecture based on the peer component, which is doomed to fail. A peer is a local user interface component that completes a task entrusted to a weak AWT object. The peer is responsible for all the specific work, including drawing itself, reacting to events, and so on, which allows the AWT component to do nothing but interact with its peers at the right time. Because the AWT class is just the shell of a more complex local peer, AWT's early developers can ↑ (i) Create components in the quickest time. For example, the Java.awt.Panel class contains only 12 lines of code.
In addition, the design of the peer component also has serious drawbacks. First, on most platforms, the peer component is drawn in the local window. A local window for each component does not have high performance, and for this reason small applications with a large number of AWT components pay a high performance price.