A Farewell to Heavyweight/Lightweight Conflicts
Problems resulting from the mixing of Swing and AWT components have been a constant source of confusion to Java newbies. This quote explains the reason for the difference very well:
Most of the issues related to mixing AWT and Swing components are related to the mixing of so-called heavyweight and lightweight components. A heavyweight component is one that is associated with its own native screen resource (commonly known as a peer). A lightweight component is one that "borrows" the screen resource of an ancestor (which means it has no native resource of its own -- so it's "lighter").
From: Mixing Heavy and Light Components
The lightweight approach, taken by Swing, is the preferred, since it consumes less resources. However, there are cases where one might need to mix the two in the same application, which can result in undesired side effects. A case in point, from the same article and where all the code used below is found, goes as follows. The menu on the right behaves correctly, while the menu on the left does not:
The reason for the difference is that the badly displayed menu in the second screenshot is Swing and lightweight, while the other menu is AWT, and therefore heavyweight. The Button is an AWT component too, therefore being heavyweight. Unless one forces a lightweight component, via setDefaultLightWeightPopupEnabled(false), to behave like a heavyweight component, unwanted side effects such as the above will result.
But all that is old news, of course.
The new news is that already with the early access release of JDK 6 Update 12 one can, without needing to do anything at all, obtain the desired effect, which is as follows:
This is exactly what one would want: the rendering of a lightweight component over a heavyweight component. Though the major features of the EA release are slated as "Windows 2008 Support" and "Java Plug-In now supports 64-bit browsers", it is this heavyweight/lightweight fix that I find the most useful (since I am neither a Windows- nor a 64-bit browser-user). If one looks through the list of issues fixed in the current JDK 6 Update 12 build, one notices that a lot of fixing has been done in the Swing & AWT packages.
The final screenshot above was taken on JDK 6 Update 12, using the code from the article referenced at the start. I.e., without doing anything special at all, no fiddling with z-order or the like, the behavior was exactly as an end user would expect it to be. Hurray!
| Attachment | Size |
|---|---|
| fig-1.png | 8.43 KB |
| fig-2.png | 7.1 KB |
| fig-3.png | 7.98 KB |





Comments
James Sugrue replied on Tue, 2008/12/16 - 5:40am
That is pretty cool - the lightweight/heavyweight thing has caused problems for me in the past. Great to see the effort still being put into Swing bug fixes
Aljoscha Rittner replied on Tue, 2008/12/16 - 7:11am
Hi!
Absolut great improvement and bug-fix. I hope this enhancement will works with TopComponents in NetBeans. I've a heavyweight Movie-Player. And this player jumps throw all slided TopComponents.
best regards,
josh.
Thierry Milard replied on Tue, 2008/12/16 - 9:17am
This is just superbe. I use for example java3D panel ... inside a Swing application.
In the past I lost so many days if not weeks to get the rendering right.
And it was never perfect : As soon as someone updated the gui ... other rendering issues rose.
If now, mixing heavy and weight components is just not troblesome anymore I just say : COOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL.
Bravo Sun, we needed this.
Thierry
PS:
By the way Sun people.... please do continue to speed the JVM start. I admit it is better since update 11 ... but still quite far from FlashVM. Those improvements are very important for us developers (ease of programming, quick jvm start ) and I am almost sure improvements on both sides are still at the begining of a long serie.
Courage Sun you are doing good. Keep the pace on and thanks for listening ;) !
Jacek Furmankiewicz replied on Tue, 2008/12/16 - 9:49am
Get the JDIC browser back into NetBeans! :-)
cowwoc replied on Tue, 2008/12/16 - 10:22am
There are still two outstanding bugs that I'm aware of that prevent Heavyweight / Lightweight mixing:
http://bugs.sun.com/view_bug.do?bug_id=6776743
http://bugs.sun.com/view_bug.do?bug_id=6783411
In other words, this isn't working yet.
Osvaldo Doederlein replied on Tue, 2008/12/16 - 11:48am
"The lightweight approach, taken by Swing, is the preferred, since it consumes less resources." - how exactly? Swing components require more classes, more objects, double buffering, and more CPU/GPU power for rendering if compared to native widgets (as the latter benefit from tight integration with the OS kernel and video drivers, remarkably on Windows that doesn't fear stuffing half of its graphics stack in ring-0). The only "light" aspect of Swing is less JNI overhead (native calls can be more coarse-grained), but since Swing's introduction the platform improved a lot in areas like JNI performance and the AWT core.
Anyway, the lightweight+heavyweight fix is hugely good news. Not too many people uses standard AWT controls these days, but I guess this will make a bigger difference for scenarios like OpenGL surfaces which are handled as "heavyweight" components. I wonder if this fix is also relevant to JavaFX, that is another "lightweight" toolkit, but integrates media decoding with native codecs.
Steve Taylor replied on Thu, 2009/01/22 - 11:36pm
suraj chandran replied on Sat, 2009/01/24 - 2:56am
Same here.... I too created an account here, just to give thumbs up to tis feature. This feature can open unimaginable avenues, which hitherto couldn't be even imagined.
+100 points
Joseph Okharedia replied on Sat, 2009/12/05 - 3:02am
Carla Brian replied on Sun, 2012/07/15 - 5:30pm
James Walker replied on Sun, 2012/10/14 - 7:00am
Lucifer Williams replied on Thu, 2012/11/01 - 8:54am
Zem Karlos replied on Thu, 2012/11/15 - 10:22pm
Indeed a nice post to have come across, I must admit that you have done a great work.read more
Nitin Khare replied on Sun, 2013/04/07 - 1:46am