Java Reference
In-Depth Information
17.2
T
HE
IBM SWT T
OOLKIT
The Standard Widget Toolkit is a complete GUI library for Java, completely
independent of Swing and AWT. It is implemented as a library of native
methods, so it cannot be ported to any Java runtime unless that platform has
the native part of the SWT library implemented for it.
17.2.1
The first question one should ask, perhaps, is why create an alternative GUI?
Good question. The answer, according to the SWT FAQ,
3
primarily has to do
with execution speed and look-and-feel similarity to native GUI applications
on each platform.
If we may editorialize, we find neither reason particularly compelling, al-
though the execution speed argument made some sense when the Eclipse
project started. Swing is unlikely to win any performance awards, even though
each version brings some improvements in speed.
4
Still, these reasons do not
seem particularly compelling for such a large duplication of effort and function-
ality.
Another GUI Toolkit. Why?
Whatever the reason, SWT exists. SWT works by providing a thin abstrac-
tion layer over native GUI features. It is a small GUI library. It is implemented
using the Java Native Interface, so it requires that a native binary library be
implemented for your platform. Fortunately, such implementations exist for
all platforms Eclipse runs on. So if you can run Eclipse, you can write and run
SWT applications.
3.
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/
faq.html
4. The question of speed in Java is a rather tired argument. If maximum speed is a primary
concern, Java is probably not your first choice of a development language. In our experience,
speed is something everybody says they need, but more often than not other considerations
such as development time and error rate are much more important. Java is fast enough for vir-
tually all MIS applications, and that is the market Java is squarely aimed at. Our computers
keep getting faster, disk drives and memory keep getting cheaper. The “resource” and “perfor-
mance” arguments only apply to applications where experienced designers would already have
chosen C or assembly language. Besides, with the JIT compilers in both Sun's and IBM's JDKs,
a well-written Java application is often as fast or faster than some other compiled languages, at
least on the second run of the code.
