Prof Java Native Interfaces Swt/Jface by Guojie

From the Publisher

Professional Java Native Interfaces takes a solutions-based approach in showing how SWT/JFace works, discussing each common component, providing useful, practical ideas, tips and techniques to make the Java developers' work easier. The author provides relevant and timely examples, both stand-alone applications and smaller code snippets that readers can incorporate into their own code.

To provide a truly real-world quality, the author builds an email/ftp client sample application to show readers how to combine everything into a presentable Java native UI application.

Product Details

• Table of Contents
• Read an Excerpt

Table of Contents

Read an Excerpt

Professional Java Native Interfaces with SWT/JFace

John Wiley & Sons

Chapter One

This chapter outlines the three main Java user interface (UI) toolkits: AWT, Swing, and JFace. First I provide a brief introduction to all three, and then I compare them, highlighting some of the advantages SWT/JFace offers. SWT/JFace allows you to access native features easily, and programs based on SWT/JFace are considerably faster than those based on Swing in terms of execution speed. SWT/JFace is designed to be very flexible, so you can program using either the traditional approach or the model-view-controller approach. After reading this chapter, you should have a general overview of SWT/JFace. The chapters that follow introduce various aspects of SWT/JFace in detail.

Evolution of Java GUI Frameworks

This section covers the following Java graphical user interface (GUI) frameworks:

* Abstract Window Toolkit (AWT): The first and the simplest windowing framework.

* Swing: Built on AWT, Swing offers peerless components.

* Standard Widget Toolkit (SWT) and JFace: SWT is a native widget UI toolkit that provides a set of OS-independent APIs for widgets and graphics. JFace is a UI toolkit implementation using SWT to handle many common UI programming tasks.

This section outlines the evolution of the Java GUI framework and highlights the key features we'll compare and contrast in the next section.

Abstract Window Toolkit

The first version of Java, released by Sun Microsystems in 1995, enabled you to create programs on one platform and deliver the products to other Java-supported systems without worrying about the local environment-"Write Once, Run Anywhere." Most early Java programs were fancy animation applets running in Web browsers. The underlying windowing system supporting those applets was the Abstract Window Toolkit (AWT).

AWT has a very simple architecture. Components, graphics primitives, and events are simply perched on top of similar elements from the underlying native toolkit. A layer of impedance matching sits between the AWT and various underlying native toolkits (such as X11, Macintosh, and Microsoft Windows) to ensure the portability of AWT.

AWT 1.0 uses a callback delegation event model. Events are propagated or delegated from an event "source" to an event "listener." The interested objects may deal with the event, and the super-event handler is not required. The event model in AWT 1.1 was reimplemented from the callback delegation event model to an event subscription model. In AWT 1.1, the interested objects must register themselves with the components to receive notification on certain events. When the events are fired, event object are passed to registered event listeners.

AWT was slightly enhanced in later releases of Java. However, even the latest version of AWT fails to delivery a rich set of GUI components. Following is a list of components provided by AWT:

* Button * Canvas * Checkbox * Choice * Container

* Panel * ScrollPane * Window

* Label * List * Scrollbar * TextComponent

* TextArea * TextField

To give you a more complete overview of the AWT user interface, I've created a simple GUI program. This tiny program allows the user to upload a photo to a server, or anywhere else. Figure 1-1 shows the user interface of the photo uploader implemented using Abstract Window Toolkit.

Click the Browse button to bring up the file selection dialog (see Figure 1-2). The name of the selected file is inserted into the text after the Photo label. The upload process starts when the user clicks the Upload button. The program exits when uploading is complete.

If you are familiar with Microsoft Windows systems, you may notice that the file selection dialog in Figure 1-2 is exactly the same as those used by native Windows programs. The Abstract Window Toolkit passes the call for file selection to the underlying native toolkit, i.e., Windows toolkit, and as a result, a native Windows file selection dialog pops up.

The Abstract Window Toolkit is sufficient for developing small user interfaces and decorations for Java applets, but it's not suitable for creating full-fledged user interfaces. Sun Microsystems recognized this as well and in 1997, JavaSoft announced Java Foundation Classes (JFC). JFCs consist of five major parts: AWT, Swing, Accessibility, Java 2D, and Drag and Drop. Swing helps developers to create full-scale Java user interfaces.

Swing

Swing is a pure Java UI toolkit built on top of the core Abstract Window Toolkit (AWT) libraries. However, the components available in Swing are significantly different from those in AWT in terms of underlying implementation. The high-level components in Swing are lightweight and peerless, i.e. they do not depend on native peers to render themselves. Most AWT components have their counterparts in Swing with the prefix "J." Swing has twice the number of components of AWT. Advanced components such as trees and tables are included. The event-handling mechanism of Swing is almost the same as that of AWT 1.1, although Swing defines many more events. Swing has been included in every version of Java since Java 1.2.

The main Swing packages are as follows:

* javax.swing: Contains core Swing components.

* javax.swing.border: Provides a set of class and interfaces for drawing various borders for Swing components.

* javax.swing.event: Contains event classes and corresponding event listeners for events fired by Swing components, in addition to those events in the java.awt.event package.

* javax.swing.plaf: Provides Swing's pluggable look-and-feel support.

* javax.swing.table: Provides classes and interfaces for dealing with JTable, which is Swing's tabular view for constructing user interfaces for tabular data structures.

* javax.swing.text: Provides classes and interfaces that deal with editable and noneditable text components, such as text fields and text areas. Some of the features provided by this package include selection, highlighting, editing, style, and key mapping. * javax.swing.tree: Provides classes for dealing with JTree.

* javax.swing.undo: Provides support for undo and redo features.

In addition to the lightweight high-level components, Swing introduced many other features over AWT. Pluggable look-and-feel is one of the most exciting of the bunch. Swing can emulate several look-and-feels, and you can switch the look-and-feels at runtime. If you do not like any of them, you can even create your own. Other features include tooltip support, keyboard event binding, and additional debugging support.

The photo uploader program can be rewritten using Swing. Figure 1-3 shows the user interface of the Swing photo uploader with Windows look-and-feel; Figure 1-4 shows the user interface with Java metal look-and-feel.

The Swing file selection dialog user interfaces for Windows look-and-feel and Metal look-and-feel are shown in Figures 1-5 and 1-6, respectively. The Swing file selection dialog with Windows look-and-feel looks similar to the AWT (i.e. the native dialog); however, they are quite different. Swing simply emulates the Windows native file dialog. If you look carefully, you'll find that some features of Windows native file dialogs are missing in the Swing file dialog. In Windows native file dialogs, you can view the files using different modes: list, details, thumbnails, and so on. Additionally, more operations are available in the popup menu when you right-click. Both of these features are not available to Swing file selection dialogs.

Swing fails to support native features of the underlying system. Another obstacle to widespread usage is that programming with Swing is very complex.

Swing is so powerful that you can use it to create full-scale enterprise Java user interface programs. So why do we see so few Swing-based GUI programs? James Gosling, creator of the Java language, said during a keynote presentation at a Mac OS X conference that there is a "perception that Java is dead on the desktop." Complexity of building Swing GUIs, lack of native features, and slow running speed are some of obstacles keeping Swing from succeeding on desktops.

Is any other Java GUI toolkit available that can create full-featured user interface programs? The answer is yes. Standard Widget Toolkit (SWT), along with JFace, provides a complete toolkit for developing portable native user interfaces easily.

SWT and JFace

Eclipse is an open source universal tool platform dedicated to providing a robust, full-featured, industry platform for the development of highly integrated tools. IBM, Object Technology International (OTI), and several other companies launched the Eclipse project in 2001. Today, the Eclipse Board of Stewards includes companies such as Borland, Fujitsu, HP, Hitachi, IBM, Oracle, Red Hat, SAP, and Sybase. With more than 3 million downloads, Eclipse has attracted a huge number of developers in over 100 countries.

The Eclipse platform defines a set of frameworks and common services that are required by most tool builders as common facilities. One of the most important common facilities is the portable native widget user interface. The Standard Widget Toolkit (SWT) provides portable native user interface support, as well as a set of OS-independent APIs for widgets and graphics.

Built on SWT, JFace is a pure Java UI framework handling many common UI programming tasks. The following subsections introduce SWT and JFace in detail.

Figure 1-7 shows the Eclipse platform's native user interface-in this case, Windows. SWT is integrated tightly with the underlying native window system.

Standard Widget Toolkit

SWT is analogous to AWT and Swing in Java except that SWT uses a rich set of native widgets. AWT widgets are implemented directly with native widgets, so to be portable it has to take the least common denominator of all kinds of window systems. For example, while Windows supports a tree widget, Motif does not. As a result, AWT cannot have the tree widget. Swing tackles this problem by emulating almost all kinds of widgets. However, this emulation strategy has some serious drawbacks. First, the emulated widgets lag behind the look and feel of the native widgets, and user interaction with the emulated widgets is quite different. Second, although Swing has been improved, Swing user interfaces are still sluggish.

SWT employs a slightly different strategy. It defines a set of common APIs available across supported window systems. For each native window system, the SWT implementation utilizes native widgets wherever possible. If no native widget is available, the SWT implementation emulates it. As mentioned previously, Windows has a tree widget so SWT simply uses the native tree widget on Windows systems. For Motif, because it does not have a tree widget, the SWT implementation provides a proper emulated tree widget. In this way, SWT maintains a consistent programming model on all platforms and takes full advantage of any underlying native window systems.

The user interface of the photo uploader, rewritten using SWT, and the file selection dialog are shown in Figures 1-8 and 1-9, respectively.

SWT is tightly integrated with the underlying native window system. Chapter 2 discusses the implementation of SWT and its advantages. Although SWT does not support pluggable look-and-feel (who needs Windows or Metal look-and-feels on a Mac, anyway?), it provides a number of other invaluable features: native UI interactions (such as drag and drop) and access to OS-specific components (such as Windows ActiveX controls like Microsoft Word, Acrobat Reader, and so on). SWT enables developers to create native user interfaces with Java. However, most programmers with experience developing user interfaces on Windows, Linux, or any of the other platforms, know that developing a GUI is a very complicated and time-consuming process. Creating a native user interface with Java is no exception. Fortunately, Eclipse provides a UI toolkit named JFace to simplify the native user interface programming process.

JFace

JFace is a UI toolkit implemented using SWT to handle many common user interface programming tasks. It is window system-independent in bots, its APIs, and implementation. JFace is designed to work with SWT without hiding it (see Figure 1-10).

JFace offers the following components:

* Image and font registries: The image and font registries help the developer to manage OS resources.

* Dialogs and wizards

* Progress reporting for long-running operations

* Action mechanism: The action mechanism separates the user commands from their exact whereabouts in the user interface. An action represents a user command that can be executed by the user via buttons, menu items, or toolbar items. Each action defines its own essential UI properties, such as label, icon, tooltip, and so on, which can be used to construct appropriate widgets to present the action.

* Viewers and editors: Viewers and editors are model-based adapters for some SWT widgets. Common behaviors and high-level semantics are provided for those SWT widgets.

SWT/JFace Advantages

Compared with AWT and Swing, SWT/JFace offers many advantages, as described in the subsections that follow.

Full Support for Native Features

SWT/JFace is tightly integrated with the underlying native window system. For example, you can create Windows user interface programs with SWT on Windows, and they look and behave the same as those developed using Visual C++. Native features are available to SWT. This is a great advantage for the user.

Let's take the photo uploader as an example. When the user hits the Browse button, a file selection dialog pops up for the user to select the photo to be uploaded. In most of the cases, the user has quite a number of pictures. File names may help the user to identify the proper photo. However, file names are not intuitive enough to the user, especially if these photos are just exported from a digital camera. The best way to assist the user in choosing the proper photo is to provide a thumbnail preview.

The file chooser in Swing does not provide the picture preview function. Sun's Swing tutorial offers a way to do this: extending the file chooser with an accessory component to display a thumbnail of the selected file. Figure 1-11 shows a custom file chooser implemented using Swing.

The Windows file chooser (refer to Figure 1-9) invoked from SWT offers more features than the custom Swing file chooser. In the custom Swing file chooser, the user has to click each file to view its corresponding thumbnail. However, the Windows file chooser displays all the thumbnails to the user (even photos in subfolders!) so he or she can easily find the proper file. Behind the scenes, Swing cannot display bitmap files (BMP) even though they're so popular on Windows and OS/2. On the other hand, SWT/JFace handles almost any kind of native image formats very well.

While the custom Swing file chooser may ultimately look even better than the Windows file chooser, it still looks strange to the user. The screen fonts in Figures 1-8 were smoothed with clear type method, except those from Swing. This means that the user selected clear type method to smooth the screen fonts' edges using the display panel of the native OS; however, Swing is unable to access this preference setting.

Such a small defect may not seem important to the developer, but to the user it is frustrating-especially when these small defects start to add up. Naturally, this leads to the loss of valuable customers. You can always hear such stories from the sales or marketing guys. This could be one of most important reasons why "Java is dead on the desktop."

Many components in Swing-including the file chooser-need improvement. You could fix them one by one and create a complete toolkit, but it is not necessary. With SWT/JFace, you do not have to create your own UI toolkit and you can still have total control of native features. If you are not satisfied with any aspect of SWT/JFace, you can always modify the source code provided.

(Continues...)

---

Excerpted from Professional Java Native Interfaces with SWT/JFace by Jackwind Li Guojie Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---