Introduction
I was teaching a one-on-one Java web services course a few weeks ago. During introductions, the delegate told me that he needed to maintain a very large Swing-based application, and didn’t know where to start. So by mutual agreement, we strayed off from the original course topics for a few days to cover AWT and Swing.
So what is the difference between AWT, Swing and JavaFX, and how would you decide which of these APIs to use?
If you want to write rich client graphical user interfaces (GUIs), you’ll need to use a GUI toolkit. You’ll probably have to decide between the standard JSE toolkits — AWT, Swing and JavaFX. There are other third party libraries as well.
Commonly used GUI libraries include:
-
AWT (Abstract Window Toolkit)
-
Swing
-
JavaFX.
-
Standard Widget Toolkit (SWT)
AWT is the first generation Java GUI toolkit, Java Swing is the second generation, and the JavaFX is the third generation. These are all mature, well-supported, standard Java GUI technologies.
You can use whichever GUI toolkit you like. One important factor to consider is finding staff who know the technologies. It will be easier to find a programmer who knows one of the standard JSE toolkits, as opposed to a third-party library like SWT or JGoodies.
AWT (Abstract Windowing Toolkit)
AWT has been around since Java 1.0, and is the original platform-dependent GUI widget toolkit. AWT was written as a Java wrapper library around native operating system GUI widgets. This wrapper code is referred to as native peer code.
The AWT components are generally thought of as “heavyweight” components. The native peer code displays the GUI widgets as operating system specific widgets. The look and feel of the GUI components is determined by the operating system. When running on Microsoft Windows, a button will look like a Windows button. When running on a Mac, the button will look like a Mac button.
This leads to portability issues. Some components have platform specific limitations. Others may not function at all depending on the OS platform.
The AWT toolkit includes GUI components, layout managers for sizing and positioning these components on the screen, and classes for handling events from those components. AWT also provides support for fonts, colours, images, data transfer, drag-and-drop, and 2D and 3D geometry.
Older GUI applications have mainly been written using AWT. However, AWT is outdated, so should definitely be avoided for new application development.
Wikipedia has a nice introductory page on AWT.
Oracle has a guide page with references to everything you’d ever want to know about AWT.
Swing
Swing was the next generation GUI toolkit after AWT. It was introduced in Java Standard Edition J2SE 1.2. Swing provides a richer set of GUI components than AWT. In addition to the familiar widgets like buttons, check boxes and labels, Swing provides more advanced components such as tabbed panels, scroll panes, trees, tables, and lists.
Swing has graphical components that aren’t limited by the native peers that AWT uses. Swing components are regarded as “lightweight” because they don’t need native resources of the operating system’s windowing toolkit. The Swing GUI elements are written in Java with no native code. Instead of wrapping native GUI components, Swing draws its components using Java 2D APIs which in turn call low-level operating system drawing functions.
Because of the pure Java design, Swing has fewer platform specific limitations and is more portable than AWT. The majority of existing Java GUI applications are based on Swing.
Swing allows you to emulate the look-and-feel of a number of operating systems. You can also use a pluggable look-and-feel giving the application a look-and-feel unrelated to the underlying OS.
Because Swing delegates the rendering of widgets to the Java 2D API, it is sometimes thought to be slower than native widget toolkits like the Standard Widget Toolkit (SWT). When the performance of Swing and SWT applications are compared, there is no consistent winner. The results of benchmarks depend on the environments. In some environments (e.g., Windows), SWT outperforms Swing. In others (Linux, VMware hosting Windows), Swing outperforms SWT.
Wikipedia has a nice introductory page on Swing.
JavaFX
JavaFX was intended to replace Swing as the standard GUI library for Java SE. The majority of new Java GUI applications are based on JavaFX.
JavaFX has a number of advantages over Swing. It is more lightweight, and has more sophisticated design controls. It uses CSS styling for components, and XML can be used to develop the GUI layout (with FXML and Scene Builder).
Swing can only be used to create rich client desktop applications. JavaFX can be used to create the same rich desktop applications, as well as rich web applications that can run across a wide variety of devices.
JavaFX is both an alternative to web-based development and an alternative to other toolkits for building GUI desktop/mobile applications.
From Java 11, JavaFX is a standalone component that must be downloaded separately. JavaFX is part of the open-source OpenJDK, under the OpenJFX project. JavaFX supports Linux, Windows, MacOS, Android, iOS, and embedded Raspberry Pi. Swing supports only the first three platforms.
Wikipedia has a fairly technical page on JavaFX.
JavaFXPorts
JavaFXPorts is the open source project that brings Java and JavaFX to mobile and embedded hardware. This includes iPhone, iPad, Android devices, and the Raspberry Pi. Gluon provides free IDE plug-ins and JavaFXPorts builds, as well as commercial support.
Swing and JavaFX are interoperable. JavaFX components can be used to enhance Swing applications, though you’d probably be better off by choosing either one or the other.
SWT (Standard Widget Toolkit)
There are other third-party libraries that you can be use to develop rich client GUI applications in Java. One of the best known APIs is SWT, maintained by the Eclipse Foundation. Unsurprisingly, the best known SWT-based application is Eclipse.
SWT is a cross-platform GUI library for JVM-based desktop applications. SWT is written as a lightweight Java wrapper around heavyweight native code objects. Because of this, SWT widgets are also regarded as heavyweight components. If a native platform GUI library doesn’t provide the required SWT functionality, SWT implements its own Java code, similar to Swing. SWT exposes programmers to more low-level native GUI code than Swing.
SWT is a compromise between the low-level performance and look-and-feel of AWT and the high-level ease of use of Swing.
As usual, Wikipedia has a good page on SWT.
Summary
In summary, you’ll probably only use AWT and Swing when maintaining existing and legacy applications. For all new rich client applications, you’ll be well advised to use JavaFX.
As far as using third-party libraries is concerned, finding a suitably skilled developer for your team can be problematic.
For more on choosing between various user interface options when developing a Java application, see my earlier blog post.
Was this post useful? Please share your comments on the blog post, and as always, stay safe and keep learning!