Swing's painting infrastructure changed quite extensively in Java SE 6. If you notice painting artifacts specific in Java SE 6 or later releases, you can try turning off the new functionality. This can be done with the property swing.bufferPerWindow.
When you are debugging the Swing code which is executed while any menu is popped up, it is recommended to use the debugger remotely. Otherwise, the debugging process and the application execution block each other, and this prevents further work with the system. If that happens, the only action that can be taken is to kill the X server for Oracle Solaris and Linux. For more information, see this bug in the Bug Database.
The following are some common Swing problems:
Painting.
Renderers.
Updating models from wrong thread.
Hangs.
Responsiveness.
Repainting issues.
isOpaque usage.
Startup: could be caused by small heap, loading unnecessary classes.
The following are some things to consider:
Buffer-per-window feature.
Native look-and-feel fidelity: Gnome vs Windows
Footprint of Swing applications.
JTable, JTree, and JList all use renderers.
Make sure that custom renderers do as little as possible.
Update models only from event dispatch thread. Otherwise the display will not reflect the state of the model.
The following identify bad renderers:
Sluggish application, especially when scrolling.
Use an optimizer to watch painting calls, look for calls to getTableCellTRendererComponent.
