Introduction to Java Swing

Lets start looking at the UI development in Java. That is done by Java Swing.

Before Java Swings – Abstract Window Toolkit (AWT)

When Java 1.0 was introduced, it contained a class library, which Sun called the Abstract Window Toolkit (AWT), for basic GUI programming. The basic AWT library deals with user interface elements by delegating their creation and behavior to the native GUI toolkit on each target platform (Windows, Solaris, Macintosh, and so on). For example, if you used the original AWT to put a text box on a Java window, an underlying “peer” text box actually handled the text input. The resulting program could then, in theory, run on any of these platforms, with the “look and feel” of the target platform; hence Sun’s trademarked slogan “Write Once, Run Anywhere.”

The peer-based approach worked well for simple applications, but it soon became apparent that it was pretty difficult to write a high-quality portable graphics programs that depended on native user interface elements. User interface elements such as menus, scrollbars, and text fields can have subtle differences in behavior on different platforms. It was hard, therefore, to give users a consistent and most importantly a predictable experience with this approach. Moreover, some graphical environments (such as X11/Motif) do not have as rich a collection of user interface components when compared to Windows or the Mac. This further limits a portable library based on peers to a “lowest common denominator” approach. As a result, GUI applications built with the AWT simply did not look as nice as native Windows or Macintosh applications, nor did they have the kind of functionality that users of those platforms wanted or expected.

The nail on the coffin was the fact that, the code did not just work the same way in different platforms. Unfortunately developers were forced to test out their code in the different platforms before they could release them, effectively killing the motto of Write Once, Run Anywhere.

Birth of Swings from Netscape IFC

In 1996, Netscape created a GUI library they called the IFC (Internet Foundation Classes) that used a totally different approach. User interface elements, such as buttons, menus, and so on, were painted onto blank windows. The only functionality required from the underlying windowing system was a way to put up windows and to paint on the window. Thus, Netscape’s IFC widgets looked and behaved the same no matter which platform the program ran on. Sun worked with Netscape to perfect this approach, creating a user interface library with the code name “Swing.” Swing was available as an extension to Java 1.1 and became a part of the standard library in Java SE 1.2.

Note
Swing is not a complete replacement for the AWT—it is built on top of the AWT architecture. Swing simply gives you more capable user interface components.

Of course, Swing-based user interface elements will be somewhat slower to appear on the user’s screen than the peer-based components used by the AWT. The point here is that, given the processing power of the modern computers, this shouldn't be a problem at all.

Why Java Swings?

Even though AWT is powerful, there are many compelling reasons as to why Swings is a more successful and preferred choice for UI programmers. They are:

1. Swing has a rich and convenient set of user interface elements.
2. Swing has few dependencies on the underlying platform. This means that it is less prone to platform-specific bugs.
3. Swing gives a consistent user experience across platforms.

But, the third advantage is also a potential drawback. If the UI elements look the same on all platforms, then they will look different from the native controls and thus users will be less familiar with them.

Swing solves this problem in a very elegant way. Programmers writing Swing programs can give the program a specific “look and feel.” This way, the users using the system wouldn't be confused by the look and feel of the system.