Difference between AWT and Swing in component rendering
What are the main differences between the swing and AWT interface building libraries in terms of how the components of both are rendered and performance?
2 answers
There are two types of components involved, the heavyweight and the lightweight components. The heavyweight components rely heavily on details implemented in native code to work (i.e. C and C++) and because of this, their performance tends to be (but not necessarily is) a little better, but making them much more difficult to use, as well as sometimes relying on specific operating system details sacrificing compatibility. The components lightweight are made 100% in Java, without requiring native code.
The heavyweight components are from AWT (for example, java.awt.Button), while the lightweight components are from Swing (for example, javax.swing.JButton). the direct use of heavyweight components has long been discouraged.
All AWT components are subclasses of java.awt.Component. One of these subclasses, java.awt.Container is special because it corresponds to a component that can contain subcomponents. A special subclass of Container is the Class javax.swing.JComponent which is the superclass of all Swing components. This hierarchy also means that any Swing components can contain subcomponents.
The drawing of all of them is based on the method paint(Graphics) from Class Component. However, it is not recommended to overwrite or invoke this method directly.
A redesign of a component can be forced with the use of the method repaint().
A component heavyweight that has its dirty screen drawing, can be redrawn by AWT using the method update(). The default implementation just cleans the drawing area of the entire component and calls paint() to redraw it, but more specialized implementations can do incremental updates or determine which areas are dirty and redraw only those. Again, the update() method does not it must be called directly.
However, the concept of incremental design and the use of update() proved confusing and almost always unnecessary, so this is not used for lightweight components. In lightweight components, a call to update() is in practice the same as a call to paint(). In the lightweight components, the paint() method implemented in the JComponent class only calls the methods paintComponent(Graphics), paintBorder(Graphics) and paintChildren(Graphics) in this order (source). As the names suggest, they respectively draw the component, draw the edge of the component, and draw the subcomponents. Although you can overwrite any of these methods, usually you will want to overwrite only the paintComponent(Graphics).
In the end, in both cases, who performs the drawing is the Class Graphics. However, AWT will always use an instance of the subclass Graphics2D, then you can make the cast safely if you need to gain access to a larger and better set of available methods.
And remembering that at the end of the day, who controls everything is the AWT. The Swing is just a layer on top of the AWT, and not a complete replacement. Swing is only a substitute for AWT when it comes to replacing heavyweight components with lightweight components.
There is one more important detail to note: JFrame, JDialog e JWindow they are not subclasses of JComponent, so they don't have the method paintComponent(Graphics), but they have the method paint(Graphics). In this case, you may then prefer to overwrite paint(Graphics) by invoking a super.paint(g) inside it. However, in the case of JFrame s and JDialog s, it might be better to add a JPanel inside and then overwrite the paintComponent(Graphics) of the JPanel.
TL; DR: that is, in the end, what matters is that to implement the design of your subclass of JComponent, you must overwrite the method paintComponent(Graphics). For subclasses of JFrame, JDialog and JWindow, you overwrite the same paint(Graphics).
More details in http://www.oracle.com/technetwork/java/painting-140037.html
In implementation, the basic difference is that AWT uses the visual component APIs of the operating system where the VM is running to create entire components with virtually all behavior being controlled by the OS.
Swing, on the other hand, draws the components from scratch using basic graphical APIs of the OS, managing most of the functioning of the components on its own.