Luis de la Rosa

Things I wish I knew when I first started using SWT on Windows

SWT on Windows was probably the "killer app" or "killer feature" of Eclipse. When Eclipse 1.0 came out, it looked great on Windows, was fast, and was indistinguishable from any other Windows app. Before that, you could always tell that a Java/Swing app was somehow different, as if you could hear the song "one of these things is not like the others". Swing has gotten better and faster, especially with the Windows XP Look and Feel, but SWT upgraded to XP quicker and is still more native and faster.

The Windows SWT implementation also has some unique features vs other Operating Systems (OS in SWT terminology) due to the SWT team taking advantage of the features of Win32, which is the Windows System (WS in SWT terminology) of Windows. It's kind of ironic, that the Java community was in a huge uproar over Microsoft's WFC (Windows Foundation Classes), which did the same thing, that is, have Windows-specific extensions. The difference it seems is that WFC was made by Microsoft and SWT is made by the independent non-profit Eclipse Foundation. Note that the architect of WFC was another one of my favorite gurus, Anders Hejlsberg, who was also the architect of the almost-VB-killer Delphi. He has more recently gone on to create C# and .NET. It's a small, strange world, eh?

Now, back to the Win32-specific features of SWT on Windows. You can embed an ActiveX control or an OLE document. What does that mean to those who don't understand those acronyms? Well, it means that you can do nice tricks like embed IE in Eclipse (although nowadays, there is a nice SWT Browser widget that accomplishes this more easily and in a cross-platform way.) There are a lot of other ActiveX controls out there though. You can also embed a Word document or an Excel spreadsheet in an SWT app because they are OLE Documents. You can read more about how to do this in a nice Eclipse Corner Article by Veronika Irvine (who is on the Eclipse SWT team).

You might think you're special if you're developing on Windows, but you will still have an initial obstacle to overcome when developing with Eclipse (vs Swing) because of Eclipse's use of native libraries. However, you'll have different moving parts to deal with.

To start off, get up to where you have a Java Project with a Package named "com.luisdelarosa.swtdemo", with a Java Class named "SWTHelloWorld". Get the source code from the previous post about SWT on a Mac.

Now, to get the red Xes to disappear:

  1. Choose "Project" | "Properties" from the main menu.
  2. Navigate to the "Java Build Path" list item, then to the "Libraries" tab.
  3. Press the "Add External JARS..." button. This will open up the "JAR Selection" dialog.
  4. Navigate down (with ECLIPSE_HOME being you Eclipse install directory) to: ECLIPSE_HOME/plugins/org.eclipse.swt.win32_3.0.1/ws/win32. (If using Eclipse 3.0, then go to ECLIPSE_HOME/plugins/org.eclipse.swt.win32_3.0.0/ws/win32.
  5. Select "swt.jar". On Windows, for some reason, there is no "swt-pi.jar".

  6. This is what the JAR Selection dialog should look like at this point. (Click on the thumbnail to see the full size image.)

    Windowsswtjar

  7. Press the "OK" button.

  8. This is what the Project Properties dialog should look like at this point.

    Windowsjavabuildpath

(Sorry if the following seems like a repeat from the last post, but writing this way makes it flow better.)

Then right-click on the SWTHelloWorld class and choose "Run" > "Java Application".

At this point, the console will come up, and you'll see a strange looking stack trace in red that says:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-win32-3063 in java.library.path

Stay calm. Although the stack trace may look a little scary, there is a simple explanation for it: SWT relies on native libraries. It uses these native libraries + JNI + Java classes to produce that nice native, fast, and responsive look and feel that we've come to love in Eclipse. On Windows, these are in native libraries take the form of ".dll" files. There are three of them in Eclipse 3.0.1:

  1. swt-win32-3063.dll - the main SWT DLL
  2. swt-win32-3062.dll - a slightly older version of the main SWT DLL
  3. javaw.exe.manifest - this enables SWT to use XP skins
  4. swt-awt-win32-3062.dll and swt-awt-win32-3063.dll - allows SWT and Swing to play nicely together

You're only a few steps away from success:

  1. While the SWTHelloWorld class is selected, choose "Run" | "Run...".
  2. That should bring up the Run dialog, which has launch configurations, with the SWTHelloWorld configuration selected.
  3. Navigate to the Arguments tab.
  4. Enter into the "VM arguments:" text box (No need for substitution because it uses a special variable):
    -Djava.library.path=${system:ECLIPSE_HOME}/plugins/org.eclipse.swt.win32_3.0.1/os/win32/x86

  5. This is what the Run dialog should look like at this point:

    Windowsrunvmarguments

  6. Press the "Run" button.
  7. You should get a nice little window that says "Hello World" and a new Java icon in your Dock.

Note that on Windows, you can get away from repeating this step by copying all those DLLs and putting them in a common place for DLLs like c:\windows\system32. If you do this, then you won't be able to use multiple versions of Eclipse using this technique. Also, when you upgrade to a newer version of Eclipse, you'll need to remember to copy the upgraded DLLs.

Another interesting thing that I found out while researching this is that there is a WinCE port of SWT, which allows you to write SWT apps for Pocket PCs. Combine this with the latest project proposal on the table: eRCP or the Embedded Rich Client Platform and Eclipse looks like it might be the next great development environment for mobile devices. Also, the folks who create the Palm development environments are basing their next generation of tools off of Eclipse. Not sure if they're going to have an SWT Palm port, however.

Update [11/3/2004 10:15 PM EST] - I added the screenshots from Windows XP.