Text text = new Text( parent, SWT.BORDER );
...
SWTBotText textBot = new SWTBotText( text );
textBot.typeText( "Hello World" );

Though SWTBot covers most of the API that SWT has to offer, there are some gaps. Say you want to maximize a Shell and afterwards ensure that certain widgets within that Shell behave as epected. And just the SWTBotShell.maximize() method is one of these missing ones. Or your application uses a custom widget that no one has written a bot for yet.

So help yourself and write your own bot.

To understand how a bot works, let us first look into one aspect of SWTBot, the threading model. Running a test with SWTBot usually involves two threads. The widgets under test run on the UI thread. The bot runs on an extra thread and communicates with the UI thread in that it posts events to the UI thread or uses Display.syncE­xec() to run code on the UI thread.

This is usually necessary because the UI code at some point calls Display.sleep() – e.g. from the main event loop or to create a blocking dialog. sleep() suspends the UI thread and waits until an event is received. If the test code (which generates the events sleep() is waiting for) was running on the same thread, it would be blocked infinitely.
However, if you can ensure that the code under test doesn’t call sleep(), then of course you can safely run your test code on the UI thread.

Once you have a clear understanding of that, writing your own bot is easy ¹.

public class SWTBotShellExtension extends AbstractSWTBot {

  public SWTBotShellExtension( Shell shell ) 
    throws WidgetNotFoundException
  {
    super( shell );
  }

  public void maximize() {
    syncE xec( new VoidResult() {
      public void run() {
        widget.setMaximized( true );
      }
    } );
  }
}

The superclass AbstractSWTBot brings syncE­xec() methods that run the a given piece of code on the UI thread. There are several overloaded variants that accept runnables with different return types. For now we will use its simplest form, syncE­xec(VoidResult) to maximize the shell without returning anything.

The test code can now execute new SWTBotShellExtension( shell ).maximize() and voila, the given shell will be maximized. If you prefer you can inherit from SWTBotShell to have access to the other bot methods from within the same instance.

As inter-thread communication is involved, you may want the bot to be more fail safe. Take a look a the snippet below:

  public void maximize() {
    new SWTBot().waitUntil( new DefaultCondition() {

      public boolean test() {
        return syncE xec( new BoolResult() {
          public Boolean run() {
            widget.setMaximized( true );
            return Boolean.valueOf( widget.getMaximized() );
          }
        } );
      }

      public String getFailureMessage() {
        return "Timed out waiting for shell to get maximized";
      }
      
    } );
  }

waitUntil() executes the test method in intervals until it either returns true or a timeout is reached. If the operation times out, an exception is thrown with a message from getFailureMessage()

This is where another of the syncE­xec() method becomes useful: syncE­xec(BoolResult). Now, the code maximizes the shell, and reports back whether the shell was actually maximized. Due to the waitUntil(), this is executed as long as takes to succeed – or until the time limit is reached.

The AbstractSWTBot also provides a notify() method that can be used send events. In our case, the maximize() method issues a resize event as if the action was initiated by a user. Other actions might not always behave so in which case you can use notify() to simulate the event.

There is certainly much more to it. But creating a simple custom bot is pretty easy, isn’t it? If you have any questions or comments, please post them here.

After being half-way through writing tests for the second class that implemented equals() and hashCode(), and more and more copying code from the existing tests and getting more and more impatient with the progress I made, I decided to write a helper class that would hopefully reduce the redundant test code.

A few iterations later I had an EqualsTester class. The general idea is to feed its assert-methods with probes that are known to be equal or unequal. They will then ensure that equals() and hashCode() work like specified as far as possible. If testing a probe fails, an AssertionError will be thrown. This is best illustrated with a code snippet:

  @Test
  public void testEqualsAndHashCode() {
    EqualsTester<Point> equalsTester = newInstance( new Point( 1, 2 ) );
    equalsTester.assertEqual( new Point( 1, 2 ), new Point( 1, 2 ) );
    equalsTester.assertNotEqual( new Point( 1, 2 ), new Point( 3, 4 ) );
  }

The factory method is just there to avoid yet another pair of angle brackets. With the given argument, a number of tests are executed to ensure that the argument

• is equal with itself (object.equals( object ) == true)
• is not equal with null
• is not equal with new Object()

By passing two objects that are considered equal to assertEqual(), you can not only ensure that equals() is implemented correctly but also that their hash code is the same.

assertNotEqual() makes sure that your equals() implementation does not accidentailly consider unequal objects as equal. By default assertNotEqual() will also check that hashCode() produces distinct results. This may improve the performance of hash tables. As it isn’t required by the general contract, it can of course be disabled.

This utility class helped me, thus I though it would be worth sharing. I hope that one or another will also find it useful.

For example, if you have

import java.lang.System;
class Example {
  void someMethod() {
    System.currentTimeMillis();
  }
}

Place the cursor on currentTimeMillis() and press Ctrl+Shift+M. This will transform the code to

import static java.lang.System.currentTimeMillis;
class Example {
  void someMethod() {
    currentTimeMillis();
  }
}

This feature has probably been here for a while and is documented and was announced in a New & Noteworthy. I only just discovered it the other day and found that it highly improves working with static imports. Maybe you find it useful too…

The long part of the story…

Tired of often manually managing static imports and encouraged by the new API for quick assists in JDT, I started writing a quick assist. This quick assist should replace qualified calls to static methods with static imports.
Only after I already had a mostly working implementation, I searched the JDT bugzilla for such an enhancement request to eventually provide a patch. Thereby I discovered that Ctrl+Shift+M already does the job.
In the end, I spent an evening coding and got to know new APIs of JDT, learned a new feature of an old shortcut and was remembered to “think first, then act”.

The plug-in extends the Project Explorer in that archive files can be expanded just like regular folders. Archive files can be extracted entirely or partially to locations in the workspace or file system. With the Open action, the content of an archive entry can be viewed in an editor.

From a Java developer’s point of view, the crux the the Project Explorer is, that it isn’t an equal replacement for the Package Explorer. When using working sets, the dynamic Other Projects working set is painfully missing. Not sure though how IDEs for other languages deal with this.

If, for whatever reason, the Project Explorer isn’t your primary view to manage development artifacts you can always press Alt+Shift+W on the current selection to show it in the Project Explorer. And from there on you can delve into the content of the archive file.

The short movie below will give you an impression of how the archive utilities work.

If you want to give it a try, the URL to the Eclipse software repository is
http://rherrmann.github.com/com.codeaffine.archive/repository
To install, choose Help -> Install New Software… from the Eclipse main menu. In the upcoming dialog, enter the above URL in the Work with field.

There is even a small homepage with some more information. The code is open source and is hosted on github.

Several things like opening nested archive files, support for other archive- and compression-formats (e.g. tar, tar.gz), an Open with… action to open archive entries in a different editor are missing. Quite annoying is, that I haven’t brought key bindings for Open to work so far. If anyone knows how to reuse the F3 key binding from the standard open command, please reply to this forum post or leave a comment on this post.

Let me know what you think. If you are missing a feature or if you found a bug, please open an issue.

For hands-on exercises I find it useful to give a starting point so that tedious steps like setting up a project and the like haven’t to be done with each exercise.
For any non-trivial exercise it makes also sense to provide the final solution. In case a training participant gets lost (s)he would certainly like to compare her/his current state with the final solution of the exercises.

All this and some more offers the Eclipse Samples Manager. Jean-Michel Lemieux and Jeff McAffer developed this Eclipse plug-in in 2007 for their Eclipse RCP book. It allows you to package and deploy code samples. The tool allows users to install a starting point, step between different iterations of samples, compare them, and reset when their changes don’t work.

If you haven’t seen the Samples Manager yet, try this short video. It will give you an overview of what the tool can be used for.

I found the Samples Manager a useful tool and thought it was worth sharing. If there is enough interest, I will publish a small how-to on creating, packaging, and deploying samples with the Samples Manager in the near future.

The RAP tooling has grown by yet another launch configuration. With the RWT Application Launcher you can run RWT applications with just one shortcut.

If you haven’t heard of RWT yet, think of it as SWT/Web. RWT is RAP without the workbench and OSGi, it plays the same role in RAP as SWT does for the Eclipse Platform/RCP. RWT lets you develop lightweight, modular, and dynamic web applications.

The short movie shows how easy it is to launch your RWT code.

From the package explorer, or from the Java editor, or any selection that points to an IEntryPoint you can choose Run As > RWT Application (or Alt+Shift+X 3 if you prefer). This command creates and runs an RWT launch configuration for the selected entry point. It starts a servlet engine, “deploys” the selected entry point, and opens a browser window with the application running therein.

As with all Eclipse launchers, the generated launch configuration can be edited and details such as the server port, the servlet path and if an internal, external or no browsers should be opened may be altered. Of course you are free to create a launch configuration from scratch if you prefer.

Apart from launching RWT applications you can also run an arbitrary web application. In the RWT launch configuration dialog you can choose a web.xml and specify the servlet path to be opened in the browser (if any).

The RWT application launcher is available since RAP 1.4. If you would like to try out this feature you can get it from the RAP downloads page. Please let us know what you think. If you are missing feature or if you find a bug, please open a bug report.