Dan Armbrust wrote: > Swings default layout managers pretty much suck. They are overly > difficult to use (especially the GridBagLayout), require large amounts > of code, and when the code is done, someone looking at it won't have a > clue what they actually look like until they see it run. One of the efforts here is Matisse -- a new layout tool in NetBeans. http://www.netbeans.org/kb/articles/matisse.html > Next, if you don't want to have a Swing application that "freezes" - or > ceases to paint the screen whenever you are doing time-consuming > calculations, you need to jump through a whole additional set of hoops > to set up the threading and proper error handling in Suns Swing world. I assumed that everyone knew that you want different things in different threads: the UI in one thread, the model in one thread, the network interface in one thread, etc... But a simpler API like foxtrot is a good idea. > The bug I discovered just yesterday in the 1.5 jdks that was really the > final straw for me - If you launch a swing application with the -Xmx > parameter to set the max heap size - and you set it to more than 1059M - > Swing refuses to paint the text of any component in your application. That does seem strange... How much memory is on the machine? How much memory is available (i.e. after the OS and the other apps are taken off the total amount of physical RAM)? Is this repeatable on other machines and/or other versions of Windows? Does the behavior always change between -Xmx1059m and -Xmx1060m? > One final point - how many _popular_ end user applications have ever > been written in Swing? http://community.java.net/javadesktop/ http://java.sun.com/products/jfc/tsc/sightings/index.html Regards, --Tom