Bei Swing handelt es sich um eine von Sun Microsystems entwickelte Grafikbibliothek, die bis zur JDK Version 1.4 vollständig in Java geschrieben wurde (100% pures Java). Seit Version 1.4 gibt es so genannte "native Bindungen" (englisch native bindings), bei denen Swing UI-Elemente direkt mit Elementen des jeweiligen Host-Systems korrelieren.
Swing und wurde erstmals mit dem JDK1.2 ausgeliefert und hatte sehr bald den Ruf eine schlechte Performance aufzuweisen und für "ernsthafte" Anwendungen ungeeignet zu sein. Das standardmäßig eingestellte Metal-Look&Feel fand ebenfalls nicht besonders viele Freunde, obwohl es durch eine einzige Programmzeile durch das native Look and Feel der Hostplattform ersetzt werden kann. Dem steht gegenüber, dass Swing sehr sauber aufgebaut und einfach zu programmieren ist. Große Teile sind sehr modular gestaltet, was eine Anpassung an eigene Bedürfnisse sehr leicht erlaubt.
Der schlechte Ruf der Swing-Klassenbibliothek begründet sich zum einen in der Implementierung in nativem Java und zum anderen in der Architektur des Java-Systems. Da Java-Programme in einer virtuellen Maschine ausgeführt werden, die in den meisten Fällen mit Just-In-Time-Compiler ausgestattet ist, dauert die Konstruktion komplexer Interface-Objekte unter Umständen sehr lange. Zusätzlich können Swing-Objekte nur innerhalb des Hauptthreads gezeichnet werden, dies führt dazu, dass die Oberfläche "blockiert", während Interface-Objekte erzeugt werden. Das ist in der Regel der Fall, wenn Pulldown-Menüs vom Benutzer ausgewählt werden. Es entsteht beim Benutzer der Eindruck der Langsamkeit. Zusätzlich zur beschriebenen Zähigkeit funtionierten viele der Interface-Elemente leicht abweichend zu ihren jeweiligen nativen Entsprechungen im Hostsystem, oder waren komplett unterschiedlich implementiert (z.B. Filerequester, Scrollbalken oder "floating" Toolbars). Einige dieser Probleme hat Sun in der Version 1.4 angegangen, indem man die Grundelemente des Hostssystems benutzt, andere lassen sich problemlos durch Benutzung von mehreren Threads bei der Interface-Konstruktion umgehen. Grundsätzlich sind Swing-Programme allerdings geringfügig langsamer als nativ implementierte Systeme. Dies führte unter anderen zu Konkurrenzsystemen wie SWT, bei denen die komplette Klassenbibliothek nativ vorliegt. Ein ähnlicher Ansatz existiert auch in MacOS X, wo man Java.Programme direkt an die Cocoa-Klassenbibliothek binden kann. Die Programme haben bei beiden Varianten eine bessere Performance und fügen sich auch nahtloser in das Look & Feel des jeweiligen Hostsystems ein, man verliert jedoch unter Umstängen einen der Hauptvorteile von Java, nämlich "write once, run everywhere", zu Deutsch "einmal schreiben, überall laufen lassen".
In folgenden Look & Feels steht Swing zur Zeit zur Verfügung: