I believe each awt component (you manipulate in java classes) maps to one and only one native screen object — probably the
so-called peer object. Native screen object is tied to the display hardware and registered (created?) with the hardware
wrapper-layer known as the OS. It takes up memory (among other resources) on the display hardware.
A lightweight component in your java source code is simply Painted as a graphic on the ancestor’s screen object (which is tied to a
heavyweight ancestor), so it doesn’t occupy additional resources on the display hardware. It’s “light” on system resources.
Also, since it’s painted as a graphic by java, the appearance is controlled by java and consistent across platforms. In contrast,
the heavy weights look native and consistent with native apps like Powerpoint. There are pros and cons. Some praise the java
consistent look and feel. Some say swing looks alien on windows.
When I say the “native screen object” corresponding to a jtable, i mean the image painted on the (heavyweight) jframe. I believe
multiple lightweights on the same heavyweight all share the same native screen object i.e. the peer object.