< Zurück | Inhalt | Weiter >

17.3.6 Closing Thoughts

Our overall impression is that SWT is more easily comprehended in its entirety than Swing. It may be easier to learn SWT first, since Swing’s core model is more complex but more powerful. But SWT and Swing weren’t developed in that order and Swing is still much more widely used.16

For many GUI applications, our feeling is that it may be faster to write in the SWT idiom. The problem lies in that SWT’s model has limitations that Swing’s does not. Notably, SWT GUI elements are in a single rigid tree struc- ture. It is not possible to have a factory class that constructs a GUI element such as a dialog box which is passed up to the caller to be grafted into place on a GUI. Instead, the parent element must be passed in, so all GUI elements be- long to the single tree from the moment they are created. Also, by introducing objects that cannot be garbage-collected, SWT brings into your application the possibility of a class of bugs that Java otherwise eliminates.

Moreover, while converting a Swing application helped give this chapter shape, we would, in general, prefer that an application be designed with its GUI toolkit in mind. You would likely make slightly different design decisions depending on which style of the GUI you choose.


15. http://www.javalinuxbook.com/

16. A gut feel—not based on any real statistics.


Up to now, we have told you again and again that SWT will work with gcj. But no Linux distribution with which we are familiar provides SWT with gcj out of the box. So how do you get SWT to play nice with gcj? Unfortunately, you have a bit of work to do. Fortunately, the work is not particularly difficult. Before we proceed, we must acknowledge those who have been there be- fore. We, too, had heard about SWT’s usability with gcj but we had never bothered to try it because there was no documentation on how to do it. We first made the attempt thanks to a great IBM developerWorks article by Kirk Vogen entitled “Create Native, Cross-Platform GUI Applications.” Follow the

URL17 to the information that enabled us to write this chapter.18

SWT source code is included in the Eclipse SDK download. See Sec- tion 10.4 for details on where and how to download and install Eclipse. Once you have Eclipse, you need to get your mits on the SWT source code. What we will do is compile the SWT source into a shared object file that we can link to any gcj application.

We’re assuming that you’ve got gcj installed. We’re assuming that you’ve unzipped the Eclipse SDK. We’re assuming you’re still reading the book. We have to make that assumption. The first thing you need to do is to unzip the

SWT source code. It is found in ECLIPSE_INSTALL/plugins/org.eclipse. platform.linux.gtk.source_2.1.2/src/org.eclipse.swt.gtk_2.1.2/ ws/gtk. If you are using (as we recommend) the GTK version of Eclipse,19 there are two files in there: swtsrc.zip and swt-pisrc.zip.

Once you have these unzipped, you have to compile the code with gcj. There are two different patterns these files follow. Files that do not contain native methods are compiled with a command line that looks like this:


17. http://www-106.ibm.com/developerworks/library/j-nativegui/

18. Please note that Kirk’s article provides links to additional documentation and to an ant buildfile that automates the steps we are going to teach you manually here. We certainly didn’t want to steal anything from Mr. Vogen (or from IBM—scary!), so we will instead direct you to the (copyrighted) IBM Web resources. The article is worth checking out. It can save you some time over our version of the process. It is up to you.

19. Be aware: As helpful as Kirk Vogen’s article and files are, they are written to an old version of gcj and they assume you are using the Motif version of Eclipse. His scripts work only with the Motif version.

17.4 SWT and GCJ



$ gcj -c SomeClass.java -o SomeClass.o

Files that do contain native methods are compiled with a command line that looks like this:

$ gcj -fjni -c SomeClass.java -o SomeClass.o

That said, it does no harm to compile a source file that has no native methods with the -fjni flag. This gives us a quick and dirty way to make our library file.

$ find . -name "*.java" -exec gcj -fjni -c {} \; -print

Remember, you are in UNIX-land. Leverage your tools! In this case, the advantage of using find is that, should the SWT source change (classes added or removed), our “compile process” will handle it. Obviously, you can take this in more sophisticated directions with make or ant. But this will get the job done for us for now.

That will compile all of the SWT source.20 Next, we want to assemble all of the object files produced into a shared object.

$ gcj -shared -o swt.so $(find . -name "*.o" -print)

Once again, we leverage our tools. This time, we use bash execution quotes around our find command to get all of the .o filenames added to our gcj command that builds the shared library. For our final trick, we will compile our HelloWorld class from the start of this chapter with gcj and our new SWT shared library:


20. When we did this with Eclipse 2.1 GTK and gcj version 3.2.2, we had one compile error where the return type of the org.eclipse.swt.custom.TableCursor.traverse() method was void, whereas the Control.traverse() method (from which TableCursor inherits) was boolean. So we hacked it. We changed the return type of TableCursor.traverse() to boolean and had it return true. We didn’t test to see if this was right! Use at your own peril!

$ gcj -classpath=~/eclipse/plugins/org.eclipse.swt/swt.jar:\

~/eclipse/plugins/org.eclipse.swt/swt-pi.jar -c HelloWorld.java

$ gcj -main=HelloWorld -o HelloWorld Hello.o swt.so

$ export LD_LIBRARY_PATH=.:~/eclipse:\


$ ./HelloWorld

Et voilà! You have the HelloWorld application! Again. But now it is an executable binary. Enjoy.


Compared to Swing, SWT is a somewhat simpler GUI library. Unlike Swing, it is Free Software and Open Source. It provides a full GUI library for use with gcj. It is part of the Eclipse project. It uses native methods that require calls to dispose of allocated objects. It has a rigid hierarchy that requires that lower level GUI components be linked to their parents when they are constructed. This means there are some limitations on how applications may be constructed. SWT is much less commonly used than Swing. Swing is the lingua franca of Java GUIs. SWT is definitely worth knowing, but if you want your skills to be marketable, it is probably best to start with Swing.


We just scratched the surface of SWT Widgets. There are a bunch we haven’t covered.


• SWT was written to support the Eclipse IDE. Eclipse is at


• An introduction to SWT can be found at the same site: http://www.eclipse.org/articles/Article-SWT-Design-1/ SWT-Design-1.php.

• Part 2 of the same article is at http://www.eclipse.org/articles/ swt-design-2/swt-design-2.php.

17.8 Exercises 399


• The full list of Eclipse technical articles (including those on SWT) may be found at http://www.eclipse.org/articles/index.php.

• A good introductory article can be found on the Developer.com Web site: http://www.developer.com/java/other/article.php/ 3330861.

• As always, consider using Google.com to find additional information.

• In dead-tree form, Chapter 10 of the book The Java Developer’s Guide to Eclipse by Sherry Shavor et al. (Addison-Wesley, ISBN 0-321-15964-0), also provides an introduction to SWT.


1. Complete the conversion of the BudgetPro class.

2. Complete the conversion of the entire BudgetPro GUI application.

3. While you have Eclipse installed, follow the instructions to unpack the SWT examples. In particular, run the ControlExample. This is an appli- cation that demos all the major Widgets, while giving you the ability to apply most (if not all) of the style values to them dynamically. It is like a Widget browser that can get you familiar with the look and feel of SWT Widgets quickly. Run it. Play with it. Become friends with it. Also, remem- ber you have the source code for this application. Want to know how to code a given Widget? Look!