- The Swing API is complicated—that’s the price to pay for flexibility provided for coding applications.
- The performance is not good; because everything is emulated and drawn using basic Graphics2D calls, software and hardware optimizations from the native system are not possible.
- Swing may not be able to take advantage of hardware GUI accelerators and special host GUI operations. As a result, Swing applications may be slower than native GUIs. Sun has worked hard on the performance of the recent versions of Swing (Java V1.4 and 1.5), and this disadvantage is becoming less noticeable. Because Swing’s design is more robust, its code base is larger. This can mean it takes a beefier machine to run it than AWT or SWT might.
- The look and feel of a Swing application is not exactly the same as those of a native application. Furthermore, the customization of the colors and font schemes of the underlying windowing system are difficult to propagate in the emulated widgets.
- Swing does not typically look like a native application. In fact, it has multiple looks, some that can emulate—although often not exactly—different hosts and some that provide unique looks.
- Creating a GUI that is accessible to people with disabilities is important. Swing offers an extensive infrastructure and API for enabling GUIs for accessibility. This support is independent of but integrates with the host accessibility support, if any.