From http://www.jguru.com/faq/view.jsp?eid=507891
Answer
SWT (Standard Widget Toolkit) is a completely independent Graphical User Interface (GUI) toolkit from IBM. They created it for their new eclipse Integrated Development Environment (IDE). IBM began work on SWT a few years ago, because Swing was still immature and . did not perform well They decided to create a new toolkit to provide better performance using native widgets The basic concepts behind SWT and AWT are fairly similar, but the implementations are quite different.:
Users write programs that use the AWT or SWT libraries for GUI widgets. AWT and SWT delegate widget control to the native components on the user's machine. The AWT Way The big difference is how the two toolkits use the native components. In AWT, native " peer "code, written in a language like C or C , is used to control the real widgets on the system. If you're running on Windows, this peer code uses MFC or Win32 calls to display widgets. On other platforms, the native GUI calls for their operating system / window manager are used Each Java Runtime Environment (JRE) distribution provides a unique set of peers for the target platform The Java Classes stay the same;.. the native code changes AWT implementations suffer three key problems because. Of this structure:
Not all platforms support the same widget set, so a "least common denominator" effect occurs. AWT only provides a very basic set of components, ones that all modern platforms provide. If you want to provide a component that exists on some platforms but not . others, you must code it entirely in Java (or use JNI, which would limit that code to one platform) This is the implementation strategy of Swing - Swing components are written in Java, drawing the new components like Trees and Tables using AWT graphics calls. A good chunk of the GUI logic is buried in C or C code (that is not delivered with the normal Java SDK distribution). This can make it difficult to find errors that occur because you can not see this code executing in a debugger. The SWT Way IBM took a different approach. Rather than write the peers in native code, they wrote a thin Java Native Interface (JNI) layer for each platform that exposes the GUI API of that platform. Java code, similar to THE AWT Native-Code Peers, uses calls to the native API for that platform to control the widgets With SWT, some of the library Java class implementations vary between platforms, rather than distributing native peer code This solves the three above problems with AWT:.. (For the first two problems ) If some platforms support a widget that others do not, the widget can be made native on those platforms and emulated on the others. In both cases, only Java code has to be written to take advantage of it. For example, Windows provides Trees and Tables, SO SWT'S Java Code Calls The MFC / Win32 Libraries to Display The Trees and Tables. IF Another Platform Didn't Provide Trees or Tables, The Java Code for That Platform COULD DRAW THEM.
