Java платформасы үшін графикалық құралдар жинағы SWT

Graphical widget toolkit for use with the Java platform

The Standard Widget Toolkit (SWT) is a graphical widget toolkit for use with the Java platform. It was originally developed by Stephen Northover at IBM and is now maintained by the Eclipse Foundation in tandem with the Eclipse IDE. It is an alternative to the Abstract Window Toolkit (AWT) and Swing Java graphical user interface (GUI) toolkits provided by Sun Microsystems as part of the Java Platform, Standard Edition (J2SE). To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using Java Native Interface (JNI) in a manner that is similar to those programs written using operating system specific application programming interfaces (APIs). Programs that call SWT are portable, but the implementation of the toolkit, despite part of it being written in Java, is unique for each platform. The toolkit is free and open source software distributed under the Eclipse Public License, which is approved by the Open Source Initiative.

The first Java GUI toolkit was the Abstract Window Toolkit (AWT), introduced with Java Development Kit (JDK) 1.0 as one component of Sun Microsystems' Java platform. The original AWT was a simple Java wrapper library around native (operating system supplied) widgets such as menus, windows, and buttons. Swing was the next generation GUI toolkit introduced by Sun in Java Platform, Standard Edition (J2SE) 1.2. Swing was developed to provide a richer set of GUI software components than AWT. Swing GUI elements are all Java with no native code: instead of wrapping native GUI components, Swing draws its own components by using Java 2D to call low level operating system drawing routines. The roots of SWT go back to work that Object Technology International (OTI), did in the 1990s when creating multiplatform, portable, native widget interfaces for Smalltalk, originally for OTI Smalltalk, which became IBM Smalltalk in 1993. IBM Smalltalk's Common Widget layer provided fast, native access to multiple platform widget sets while still providing a common API without suffering the lowest common denominator problem typical of other portable graphical user interface (GUI) toolkits. IBM was developing VisualAge, an integrated development environment (IDE) written in Smalltalk. They decided to open source the project, which led to the development of Eclipse, intended to compete against other IDEs such as Microsoft Visual Studio. Eclipse is written in Java, and IBM developers, deciding that they needed a toolkit that had "native look and feel" and "native performance", created SWT as a Swing replacement.

SWT is a wrapper around native code objects, such as GTK objects, Motif objects etc. Because of this, SWT widgets are often referred to as "heavyweight", evoking images of a light Java wrapper around a "heavy" native object. In cases where native platform GUI libraries do not support the functionality required for SWT, SWT implements its own GUI code in Java, similar to Swing. In essence, SWT is a compromise between the low level performance and look and feel of AWT and the high level ease of use of Swing. According to the Eclipse Foundation, "SWT and Swing are different tools that were built with different goals in mind. The purpose of SWT is to provide a common API for accessing native widgets across a spectrum of platforms. The primary design goals are high performance, native look and feel, and deep platform integration. Swing, on the other hand, is designed to allow for a highly customizable look and feel that is common across all platforms." It has been argued that SWT features a clean design, in part inspired by Erich Gamma of Design Patterns fame. SWT is a simpler toolkit than Swing, with less (possibly) extraneous functionality for the average developer. This has led some people to argue that SWT lacks functionality when compared to Swing. James Gosling, the creator of the Java language, has argued that SWT is too simple, and is a difficult toolkit to port to new platforms for the same reason that AWT once had porting problems: that it is too simple, too low level, and too tied to the Win32 GUI API, leading to problems adapting the SWT API to other GUI toolkits, such as Motif and OS X Carbon. This deep integration can be useful in a number of ways, for example enabling SWT to wrap ActiveX objects on Microsoft Windows.

SWT was designed to be a high performance GUI toolkit; faster, more responsive and lighter on system resource usage than Swing. There has been some attempted benchmarking of SWT and Swing, which concluded that SWT should be more efficient than Swing, although the applications benchmarked in this case were not complex enough to draw solid conclusions for all possible SWT or Swing uses. A fairly thorough set of benchmarks concluded that neither Swing nor SWT outperformed the other in the general case.

Due to the use of native code, SWT classes do not allow for easy inheritance for all widget classes, which some users consider can hurt extensibility. Both toolkits support writing new widgets using only Java code, however in SWT extra work is needed to make the new widget work on every platform. If this is not done, memory leaks or other unintended behavior may result. On this matter, some have commented that "explicitly de allocating the resources could be a step back in development time (and costs) at least for the average Java developer" and that "this is a mixed blessing. It means more control (and more complexity) for the SWT developer instead of more automation (and slowness) when using Swing." SWTSwing is a project to provide a Swing back end for SWT. In effect, SWT could be run using Swing native objects instead of, for example, GTK or Windows native objects. This would enable SWT to work on every platform that Swing supports. Starting in 2006, there was an SWT 3.2 port to the programming language D called DWT. Since then, the project supports Windows 32 bit, and Linux GTK 32 bit for SWT 3.4. The DWT project also has an addon package that contains a port of JFace and Eclipse Forms. With JavaFX becoming part of the Java SE platform there has been interest in developing a backend for SWT that relies on JavaFX in a similar way to SWTSwing relies on Swing. A prominent project trying to achieve that was SWT on JavaFX which became part of e(fx)clipse in 2014.