You're going to find that there is one additional requirement for running an SWT application: You must add the native library to your runtime environment. In Linux that would be a shared library, but in Windows you use a DLL. In this step I'll show you a rather nonintrusive way to include a DLL; this method is best used when a new DLL is being tested .
In a later step I'll show you how to reconfigure your machine so that you don't have to modify each individual launch configuration. So far, I haven't even mentioned what the code does. Let's get it to run, and then I'll review the source in a little more detail. First, try to run the class. This time, you'll use the Run menu from the Eclipse main menu bar.
q 9.6(a) Select the HelloSWT class by left-clicking on it.
q 9.6(b) From the main menu bar, select Run/Run As/Java Application.
This will create a launch configuration for HelloSWT with the default characteristics and then attempt to run it.
Unfortunately, you won't meet with a lot of success, as you can see in Figure 9.43. And, since the Console view is rather small, it's not easy to see the error.
The easiest way to see the error is to expand the Console view. Like any other view, you can expand the Console by double-clicking its title bar.
q 9.6(c) Double-click on the Console view's title bar to expand it.
You will see the display shown in Figure 9.45. Note the error highlighted in the figure.
This is an UnsatisfiedLinkError, which indicates that the Java Virtual Machine (JVM) was unable to find the implementation of a native method. As I explained at the beginning of this step, you need to include the native library in your runtime environment.
Restore the Console view to its normal size by double-clicking on the title-bar again.
q 9.6(d) Double-click on the Console view title bar to return it to normal.
Adding the library to your runtime environment is accomplished by adding a runtime switch to your JVM. This is done in your launch configuration. But before you can do that, you need to know what switch to add. The switch is of the following format:
-Djava.library.path=$LIBPATH
The contents of the $LIBPATH variable depend on the operating system, the version of Eclipse, and where you installed it. In Step 2.1(h) I had you write down a value called $ECLIPSEINST, which was the directory you extracted Eclipse into. For example, I am using Windows and I installed Eclipse in "C:\Program Files," so my $ECLIPSEINST is "C:\Program Files." When you use a file extraction utility to extract the Eclipse files from the ZIP file, it creates another folder named "eclipse" under your install folder. This is now your "base" folder. We'll call that $ECLIPSE.
Eclipse by default is installed under your install folder in a folder called "eclipse," so the base folder is $ECLIPSEINST\eclipse. Let's call this the base Eclipse path, $ECLIPSE.
q 9.6(e) Save the base path as $ECLIPSE: _________.
You now need to find the folder containing the native library and the name of that library (actually, the library will be used a little later, but it's best to do the work now and save the results for later). In Windows, you can use the Window command line to find this information, as shown on the following page.
q 9.6(f) Start a Windows command line and execute the following commands.
You can do this by going to the Start menu, selecting Run..., and then typing in the value "cmd" and pressing Enter. This will start a command line. Then follow the script below (you type in the portions in bold):
Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\>cd c:\Program Files\eclipse C:\Program Files\eclipse> cd plugins C:\Program Files\eclipse\plugins> dir *swt* Volume in drive C is Local Disk Volume Serial Number is 88F5-29E7 Directory of C:\Program Files\eclipse\plugins 03/28/2003 04:25p <DIR> org.eclipse.swt.win32_2.1.0 03/28/2003 04:25p <DIR> org.eclipse.swt_2.1.0 0 File(s) 0 bytes 2 Dir(s) 31,234,199,552 bytes free C:\Program Files\eclipse\plugins>cd org.eclipse.swt.win32_2.1.0 C:\Program Files\eclipse\plugins\org.eclipse.swt.win32_2.1.0>cd os\win32\x86 C:\Program Files\eclipse\plugins\org.eclipse.swt.win32_2.1.0\os\win32\x86>dir Volume in drive C is Local Disk Volume Serial Number is 88F5-29E7 Directory of C:\Program Files\eclipse\plugins\org.eclipse.swt.win32_2.1.0\cs\win32\x86 03/28/2003 04:25p <DIR> . 03/28/2003 04:25p <DIR> .. 03/27/2003 100:01p 278,528 swt-win32-2133.dll 1 File(s) 278,528 bytes 2 Dir(s) 31,234,199,552 bytes free
cd c:\Program Files\eclipse
(this is your $ECLIPSE base directory from Step 2.1(h))
cd plugins
(changes to the plugins folder)
dir *swt*
(lists everything with "swt" in it)
At this point, you'll see a directory. Copy down the value with "win32" in it (this is the value $LIBVERSION)
cd org.eclipse.swt.win32_2.1.0
(this is $LIBVERSION from Step 4)
cd os\win32\x86
(this gets you to the Windows32/Intel folder)
dir
Another directory. Copy the name of the file in it.
(this is the value $LIBNAME)
So, on my machine, the values are as follows :
$ECLIPSE | c:\Program Files\eclipse |
$LIBVERSION | org.eclipse.swt.win32_2.1.0 |
$LIBNAME | swt-win32-2133.dll |
The $LIBPATH value is simply a folder. On a Windows machine, the value is
$ECLIPSE\plugins\$LIBVERSION\os\win32\x86.
On my machine, that makes it the following:
C:\Program Files\eclipse\plugins\org.eclipse.swt.win32_2.1.0\os\win32\x86
Your values should be very similar. Knowing them, you can now modify your launch configuration. You should double-check to make sure that $LIBNAME matches the name of the file that triggered the UnsatisfiedLinkError back in Figure 9.45. In my case, you can see that the name is swt-win32-2133 in both cases, so I definitely found the correct library. If these values don't match, then you have a configuration problem with your Eclipse environment. Chances are, though, that if you had that bad an environment, Eclipse wouldn't run at all, since Eclipse depends on SWT for its user interface.
q 9.6(g) Save the value for $LIBVERSION: __________.
q 9.6(h) Save the value for $LIBNAME: ___________.
q 9.6(i) Save the value for $LIBPATH: ___________.
The next task is to modify the launch configuration. To do this, you need to bring up the list of launch configurations using the Run ... option of the Run menu.
q 9.6(j) From the Eclipse main menu bar, select Run/Run ...
This brings up a list of launch configurations. HelloSWTshould already be selected, since it's the last one you ran. If not, select it. Now you want to modify the arguments passed to the JVM.
q 9.6(k) Select the Arguments tab.
There are two kinds of arguments: arguments passed to the program (which can be accessed via the args array in the main method) and arguments passed to the JVM (which affect how the JVM operates). This is a JVM argument, and is added to the box marked VM arguments. Remember, in 9.6(i) you wrote down the value for $LIBPATH. On my machine, it was
C:\Program Files\eclipse\plugins\org.eclipse.swt.win32_2.1.0\os\win32\x86
Add this to the VM arguments with the following formula:
"-Djava.library.path=$LIBPATH"
Remember to include the quotes, since you may have a space in one of your folder names .
q 9.6(l) Add the library path argument to the JVM and click Run.
Finally, you will see a small window pop up, as shown in Figure 9.49. There are no decorations; the only thing even slightly custom is the HelloSWT in the title bar, but it is nonetheless a real, complete SWT window.
After you've admired your handiwork for a while, close it, because there's a lot more work to do.
q 9.6(m) Close the window.
Note | You may still be having problems getting your program to run. If you continue to get the UnsatisfiedLinkError message, then you might have had a typo on Step 9.6(l). You can either try to fix it, or simply wait for Step 9.7, where I show you an alternative technique for setting up your runtime environment. |
import org.eclipse.swt.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*;
As you saw during editing, only one of these imports is actually needed, the one for org.eclipse.swt.widgets. The widgets package contains the definitions for most of the basic SWT classes, including Display and Shell.
public class HelloSWT { public static void main(String[] args) {
This is standard code for any runnable Java application, SWT or not.
// Create a standard window Display display = new Display(); Shell shell = new Shell(display); shell.setText("HelloSWT");
This is standard interface code. The Display object communicates with the operating system, while the Shell object defines the top-level window. The only "custom" code is the setText call, which sets the text of the title bar.
// Final setup - set size and show the window shell.setSize(150, 50); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); }
The setSize call sets the initial size of the window in pixels. After that, the window is opened and then the program goes into a standard event-dispatching loop (this is reminiscent of the earliest days of Windows or OS/2 GUI programming, where you handled each event yourself). This is what the primary thread for any SWT application does: sleep and dispatch.
// When done, clean up resource and exit display.dispose(); } }
At this point, it disposes of the Display object, which releases any resources. This is one of the knocks on SWT; the programmer must manually release resources. For example, a Color object is a resource that must be released when no longer in use.