You probably never paid much attention to the disposal of widgets except that “master widget” you call dispose() on (usually a shell).. and just because of this, it’s time to dig into the “why”, “what” and “no kidding” of MenuManagers as there are undoubtedly a few of the “no kidding” unless you are already fully familiar with them.

If you look at the MenuManager API, you’ll see an often overlooked dispose() method. MenuManagers need disposal?! Yep, they sure do. Here’s a seemingly harmless sample snippet. We create a Shell, a Toolbar, on which we create a MenuManager, and then we dispose the toolbar. You’d think that the MenuManager would get disposed also wouldn’t you? It doesn’t. Where is it? In memory.

import org.eclipse.jface.action.Action;
import org.eclipse.jface.action.MenuManager;
import org.eclipse.jface.action.ToolBarManager;
import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.ToolBar;

public class MenuManagerTest1 {

    public MenuManagerTest1() {
        Display display = new Display();
        Shell shell = new Shell(display, SWT.SHELL_TRIM);
        shell.setLayout(new FillLayout());

        ToolBarManager tbm = new ToolBarManager(SWT.FLAT | SWT.RIGHT);
        tbm.add(new OneAction());
        ToolBar tb = tbm.createControl(shell);

        MenuManager mm = new MenuManager("Test Menu");
        mm.add(new OneAction());
        tbm.setContextMenuManager(mm);

        // dispose shell, this will dispose all sub-widgets as well
        shell.dispose();

        // check status of our stuff
        System.out.println("Toolbar is disposed? - " + tb.isDisposed());
        System.out.println("Menu is disposed? - " + mm.getMenu().isDisposed());
        System.out.println("ToolbarManager contains what? " + tbm.getItems());
        System.out.println("MenuManager contains what? " + mm.getItems());
    }

    class OneAction extends Action {
        public OneAction() {
            super("Test Action");
        }

        @Override
        public void run() {
            System.out.println("Action was run");
        }
    }

    public static void main(String[] args) {
        new MenuManagerTest1();
    }

}

The printout when running this will look like;

Toolbar is disposed? - true
Menu is disposed? - true
ToolbarManager contains what? [Lorg.eclipse.jface.action.IContributionItem;@16fe0f4
MenuManager contains what? [Lorg.eclipse.jface.action.IContributionItem;@19d0a1

Ok, so that's not the most intriguing printout ever, but it's mostly to show that the items are still there. The reason a manager doesn't get disposed should be pretty obvious: It's not a widget, it has no disposable parent (which would also have to be a widget), thus, it exists as long as you let it exist. There is of course a reference to the actual Menu inside the MenuManager, which is disposed as you can see above.

So why aren't MenuManagers auto-disposed in some other fashion, like when the menu is disposed? For good reason. You can create them without a parent widget which means you can keep them around and re-use them like a Factory and because of this, there is no auto-dispose when the menu is hidden. It's actually to make life easier for you even if it sometimes doesn't feel that way.

Disposing MenuManagers

There's two ways you can go about dealing with disposing your MenuManagers. Here's the first one (which might be obvious);

Assume you have a few MenuManagers in your ViewParts or EditParts. If you are creating them inside methods, you will want to refactor them out and create them only once for your class. They should be accessible and re-used throughout the life of the ViewPart and disposed when the ViewPart is disposed. This is very important! If you do not dispose it, it will not be gone, and you will most likely end up with a memory leak (as the above snippet showed). Here's a typical ViewPart dispose() override:

@Override
public void dispose() {
        try {
            if (_toolbarMenu != null) {
                _toolbarMenu.dispose();
                _toolbarMenu = null;
            }

        }
        catch (Exception err) {
            // do something with exception
        }

	    // remember to keep it going!
        super.dispose();
}

The second option is for the "show once" menus that you may have. How do you dispose those? Ideally the same as #1 but if you really have to dispose them differently, the easiest way to do it is to "auto dispose" them once the user has seen the menu and closed it or selected something from it. You will most likely create your Menu object from a call to menuManager.createContextMenu(...), so after this when you have the Menu object available, you do something like this;

final MenuManager mm = new MenuManager("Menu");

// ... various manager-related code here

// create menu object on widget
Menu menu = mm.createContextMenu(parentWidget);

// add a listener that disposes the MenuManager once user has seen the menu
menu.addMenuListener(new MenuListener() {

	 @Override
	 public void menuHidden(MenuEvent e) {
	     // dispose asynchronously or it'll dispose too fast and menu item clicked won't be run
	     Display.getDefault().asyncExec(new Runnable() {

		 @Override
		 public void run() {
		     mm.dispose();
		 }

	     });
	 }

	 @Override
	 public void menuShown(MenuEvent e) {
	 }

});

It's not the prettiest solution, but it works. Ok, so the disposal is covered now, no more leaks. Yay for us!

There is one more thing to bring up that you may/may not encounter, but if you do, it would probably be a head-scratcher.

Dynamic Menu Items

Here's a scenario that happened to me and at first seemed to be a bug:

We have a lot of tables in our application. We also have a section where users can create their own custom filters. These filters show up in our menus when you right click a table or open a menu on the toolbar. When a filter is in use, the corresponding menu item for that filter is checked. Each filter is wrapped in an IAction that overrides equals() and hashCode() that both check to see if the wrapped Filter object is the same. Thus, any action using the same filter object will return true in the equals() check.

We have an IMenuListener on the menu, so whenever the user opens the menu, just as it's being shown, we remove all old menu items in the "Filters" menu and re-create them (as filters may have changed by the user without our knowledge). We then "check" (checkbox) them according to what filters are active in the table. All this works fine, and here's where the issue arose;

We also have a MenuManager on our toolbar (ToolbarManager) associated with the table. This toolbar menu shows the exact same filter menu when popped up, through the same methods. The issue is easiest described through this chain of events...

1. User opens right click filter menu, selects a filter, item is checked, filter is applied to table.
2. User looks at toolbar menu, sees filter checked (do note this is the first time the toolbar menu was opened). Closes menu without selecting anything.
3. User opens right click filter menu again, selects same filter as before (the now checked one). Item is no longer checked, filter is removed from table.
4. User opens toolbar menu again, sees the recently cleared filter still checked(!). At this point it will always stay checked. Had we looked at the menu when stuff was unchecked, it would forever be unchecked.

I debugged this for a long time until I to my horror realized that despite me calling removeAll() and re-creating all MenuManager items in the "Filters" menu on each popup, internally, in the Menu widget itself, the removeAll() on the MenuManager removed nothing on the Menu widget. All MenuItems were still there! Hmm, what was going on? what was I missing? Why didn't removeAll() remove all MenuItems as well?

I debugged some more and noticed some code inside the MenuManager source code that looks like this:

for (int i = 0; i < mi.length; i++) {
    Object data = mi[i].getData();

    if (data == null || !clean.contains(data)) {
	mi[i].dispose();
    } else if (data instanceof IContributionItem
	    &amp;&amp; ((IContributionItem) data).isDynamic()
	    &amp;&amp; ((IContributionItem) data).isDirty()) {
	mi[i].dispose();
    }
}

This loop first of all removes all items that are not the same as before (that are in the clean array), that's good. But as I checked what got disposed, our filter items were never removed... as they are the same as before! Aha! So the second part of the if-statement checks to see if the item is Dirty or Dynamic. This was the first I had heard of Dynamic menu items and it felt like I had read the API through and through many times. The API for isDynamic() says:

Returns whether this contribution item is dynamic. A dynamic contribution item contributes items conditionally, dependent on some internal state.

Cryptic to say the least, and easily overlooked as it's very non-descriptive, but with the above looping code and how we deal with these special actions - it kind of fits. We depend on the items having checkmarks which depend on an internal state (which is; if the table filter is active or not). The MenuManager can't figure that out by itself of course, so we need to help it. The solution to this problem is obvious at this point. If isDynamic() returns true it will be disposed for us, so we need to implement that and return true.

In our code more or less everything is an IAction, for our FilterAction we create a DynamicFilterAction class that extends ActionContributionItem and then we override isDynamic() and return true.

This ensures that there is no "old" items in the menu (as now our Dynamic menu items get disposed) when we create the new one, and as such, the "checkbox issue" goes away and everything works as intended. The final code looks something like this;

class DynamicFilterAction extends ActionContributionItem {

        private FilterAction _action;

        public DynamicFilterAction(DataFilter df) {
            super(new FilterAction(df));
            _action = (FilterAction)super.getAction();
        }

        public void setChecked(boolean checked) {
            _action.setChecked(checked);
        }

        @Override
        public boolean isDynamic() {
            return true;
        }
}

Final Words

Hopefully this gives you a better insight into the rather simple but tricky world of MenuManagers and how they work. Taking good care of them will ensure that you at least don't have to worry about them sticking around in memory or doing things you didn't expect.

Happy menu managing!

1. Brackets inside comments are no longer mistaken for “matching” brackets
2. If the starting bracket and end bracket were not in the same location, the connecting line would draw funny, now it draws a bend
3. Preferences page moved to under Java then “Java Editor”. Search for helper if you can’t find it in the Preferences dialog.

Here’s a picture of the “fixed” line drawing:

You can update via the update site or download and install/update manually. For more info go to the java source helper page.

What does that mean? It’s probably easier to explain by example. Imagine you have a project that has two dependencies (can be your own created jars or third party, or anything Maven-buildable really). Your first dependency uses Log4J v1.0. Your second dependency uses Log4J v1.1. When you compile this project Maven will by default use the “nearest wins” strategy, meaning it might pick Log4J v1.0 or Log4J v1.1, whichever is nearer in the transitive hull of dependencies. What you probably wanted however, was for the compilation to tell you that you have two “modules” depending on the same library, but different versions of that library. Log4J is perhaps not the best example, but imagine that the dependency in question is a mission-critical dependency, and that any version discrepancy may cause catastrophic failures that can be very hard to track down via debugging.

To solve this I wrote a Maven plugin nearly a year ago that we are now using for every Maven-built project in our company. It’s a simple plugin that does the complex task of detecting all version clashes (even deeply nested ones) and will report them back to you either as warnings or errors (or ignore them). This project was submitted to the Maven team a while back but has not been integrated as a default Maven plugin yet, so it will now become a downloadable Software Project on Hexapixel until it hopefully becomes a standard module.

So how do you use it? Here’s a brief explanation and some examples of usage. If you’d rather skip to the plugin “homepage”, please follow this link.

Usage / Configuration

You can either run the clash-detector manually from the command line, or (the best option) is to add it to your POM (ideally your parent POM that all your projects use, you do have one right?) so that it is run automatically whenever you do builds.

There are only two options you can configure, one is the level of warning the plugin should do. By default the level is FAIL, meaning your build will fail if the plugin detects any clashes. The level can be changed either on the command line by supplying the parameter -Dhalt= where the right hand of the equals sign is one of FAIL, WARN or DEBUG. For the POM the same parameter is configured by supplying the same keyword inside a <halt /> tag such as: <halt>WARN</halt>

The second parameter is the level of detection the plugin should do. There are two modes, SHALLOW and DEEP. By default the level is DEEP where clash detection is not limited to the immediate level of the dependency, but also deeply nested dependencies. Shallow detection is only one level down and will not detect deeply nested dependency clashes. This is for example good for when you only care about clashes of your own jars (although I would strongly advice never using it unless really necessary).

Here are two snippets showing how to run the clash detector from the command line and how to configure it inside your POM.

Command Line

To invoke it from the command line you simply run it like this:

mvn breakonversionclash:clash-detection -Dhalt=FAIL -Ddepth=SHALLOW

In your POM

<build>
	<plugins>
		<plugin>
			<groupId>com.hexapixel.maven.plugins</groupId>
			<artifactId>
				maven-breakonversionclash-plugin
			</artifactId>
			<version>1.0.1</version>
			<executions>
				<execution>
					<configuration>
						<!-- Options: FAIL, WARN, DEBUG (default is FAIL) -->
						<halt>WARN</halt>
						<!-- Options: SHALLOW, DEEP (default is DEEP) -->
						<depth>DEEP</depth>
					</configuration>
					<phase>compile</phase>
					<goals>
						<goal>clash-detection</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>

Plugin in Action

Here is a typical output the plugin will produce:

 [INFO] [breakonversionclash:clash-detection {execution: default}]
 [INFO] Checking for dependency version clashes...
 [INFO] Halt mode is: 'warn'. Depth mode is: 'deep'.
 [WARNING] ------------------------------------------------------------------------
 [WARNING] Dependency version clash on 'commons-logging' [1.0.4, 1.1.1]
 [WARNING] ------------------------------------------------------------------------
 [WARNING] Clash 1: commons-logging:commons-logging:1.0.4
 [WARNING] Clash 2: commons-logging:commons-logging:1.1.1
 [WARNING]
 [WARNING] Artifacts using different versions of 'commons-logging:commons-logging':
 [WARNING] - org.hibernate:hibernate:jar:3.2.6.ga
 [WARNING] - com.our.project:plugin-domain:jar:1.0.0.0-SNAPSHOT
 [WARNING]
 [WARNING] Dependency trail for 'commons-logging:commons-logging:1.0.4'
 [WARNING] - Node 1: com.our.project:plugin-testdata:pom:1.0.0.0-SNAPSHOT
 [WARNING] - Node 2: com.our.project:plugin-testdata-source:zip:small-datasets:1.0.0.0-SNAPSHOT
 [WARNING] - Node 3: com.our.project:plugin-testdata-generator:jar:1.0.0.0-SNAPSHOT
 [WARNING] - Node 4: com.our.project:plugin-domain:jar:1.0.0.0-SNAPSHOT
 [WARNING] - Node 5: org.hibernate:hibernate:jar:3.2.6.ga
 [WARNING]
 [WARNING] Dependency trail for 'commons-logging:commons-logging:1.1.1'
 [WARNING] - Node 1: com.our.project:plugin-testdata:pom:1.0.0.0-SNAPSHOT
 [WARNING] - Node 2: com.our.project:plugin-testdata-source:zip:small-datasets:1.0.0.0-SNAPSHOT
 [WARNING] - Node 3: com.our.project:plugin-testdata-generator:jar:1.0.0.0-SNAPSHOT
 [WARNING] - Node 4: com.our.project:plugin-domain:jar:1.0.0.0-SNAPSHOT
 [WARNING] Found 1 dependency version clash

Let’s go over this even though it might be mostly self explanatory.

We have configured the plugin to only warn us when there is a clash, and to do a “deep” check, meaning it will not only check immediate dependencies, but also dependencies of dependencies.

It tells us that we have a clash on the usage of ‘commons-logging’ and that the two clashing versions are version 1.0.4 and version 1.1.1 of commons-logging.

Then it tells us what jars are using commons-logging, in this case it’s our dependency on Hibernate and our own plugin-domain project.

It then shows us the dependency “trail” for each clash, meaning, it shows what depends on what all the way to the actual dependency of ‘commons-logging’, so that you can easily pinpoint what jars need adjusting so that the clash goes away.

Download / More Info

For downloads (binary and source) and more info, please go to the Version Clash Plugin Page.

What does this mean for you, the user? Not a whole lot, except that Microsoft wants to know that you are using a “ribbon look-a-like” widget commercially and they want you to get a license. They have a site set up where you can license the Office UI (which includes the Ribbon), so if you must, you probably should read through it and see how it applies to you. I believe it’s free, but I haven’t taken deep look at it yet. The link to this is http://msdn.microsoft.com/en-us/office/aa973809.aspx.

And another interesting Ribbon related link is something Tom Schindl just sent me, which is a Bugzilla entry for a request to add the Ribbon API to SWT. You can find that here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=90145. I think it would be fantastic as then it would be native and not custom drawn like the current Ribbon.

A new version of the Java Source Helper is out. This version is almost a rewrite of the entire code as it now uses the Java AST tree for parsing code. This should make it much more “happy” with custom formatted code. The popup will also show the parent-scope history to give you an even better idea of where you are in the code.

There are quite a bunch of new features, and I tried to include all requests I’ve gotten so far (although some may not have made it in yet). In any case, the details page contains full info including new screenshots, new download links, etc. Go check it out!.

In our case, we wanted the normal Eclipse workspace logic so that users could create multiple “RCP Workspaces” and load whichever they wanted at startup, but we also wanted all of our custom RCP application specific data in the same directory (along with any other files we felt like creating), and we wanted to customize the dialog where the user picks a workspace. In the end, as you have probably guessed by now, we used nearly none of the default Eclipse workspace implementation, but managed to get RCP to believe that we were, and we got all the features we required in there as well.

This article will explain how we went about doing this, and will show you (with full source code of course) how you can implement exactly the same thing. And it’s much easier than it may sound.

The Magic Parameter

Everything starts with one little command line parameter that tells Eclipse we will be in charge of specifying where the workspace goes. Obviously we need to do this very early in the application or else by the time we have a UI, Eclipse has no place to put preferences. And if we do it too late, Eclipse will exit with an exception saying that it has no workspace. The “Program Argument” that makes it possible for us to define a workspace at runtime looks like this: -data @noDefault.

If you look at your “Run Configurations” in Eclipse (“Run” menu, then “Run Configurations…”) and click the “Arguments” tab, you will probably see a few cryptic entries that Eclipse has created for you, they look like this: -os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl}. By appending our @noDefault argument, we end up with this: -os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -data @noDefault.

Here is a screenshot of how it would look when appended:

So what does that parameter do? It simply tells Eclipse not to use any default workspace location (or “OSGI instance area” as it’s called in the API) when it starts up and expects us to provide it instead. Here’s an API link to the document explaining the different Eclipse runtime options you can set (including the ones mentioned here).

Telling Eclipse The Location Manually

So, where and how do we tell Eclipse that we have a “workspace home” that we want it to use? As I mentioned before, we need to do it early. That means we need to do it in Application.java and more specifically in the public Object start(IApplicationContext context) throws Exception { method. By default this method will mostly be empty except for some Eclipse specific code (undoubtedly generated by Eclipse when you created the RCP project), but we’ll soon change that. Eclipse will expect us to set the necessary location by modifying the “InstanceLocation” on the Platform. We can get the Location by doing a one-line call like this: Location instanceLoc = Platform.getInstanceLocation();. Assuming we already have a specific workspace location in mind, we could do the following:

try {
	// fetch the Location that we will be modifying
	Location instanceLoc = Platform.getInstanceLocation();

	// set location to c:\temp
	instanceLoc.set(new URL("file", null, "c:\\temp"), false);
}
catch (Exception err) {
	...
}

When we create the URL we tell it that the protocol to use is a file. We also tell it that the host is null and that the file in question is c:\temp (which is actually a directory of course). The last false that we pass to the set method is whether we want to lock the workspace location (which we don’t).

We have now satisfied Eclipse’s needs for custom-defining a workspace, and when you start your product or RCP application, you should see that Eclipse has created a .metadata directory underneath it. But as we hardcoded the path to c:\temp, this doesn’t let us “customize” it much does it? What about “Switch Workspace” functionality and asking the user what workspace they would like to pick? (or create)

Asking The User

In our case, we ask users at startup what workspace we should use (Just like Eclipse does). We do various checks to see if the directory they pick is already a workspace, if it’s writable/readable, and so on. If everything is OK, we return the selected directory to the previous code exmple and put it where we used c:\temp before.

To make it easy, you could re-use code from the “Select workspace dialog” from Eclipse, but we want ours custom, so I’ll explain how that’s done.

Let’s create a class called PickWorkspaceDialog, as we’ll re-use this for the Switch Workspace action later, we’ll make it with a constructor that takes a boolean that defines whether it’s the normal “startup pick workspace” dialog or if it’s the “switch workspace” dialog. As Eclipse already has a pretty nice dialog that we can re-use that lets us put an image and a message at the top, we’ll be extending TitleAreaDialog.

While we’re at it, lets create features for cloning a workspace and a combo that remembers our last selected ones as well.

As it’s a lot of code to paste into an article – and I think a lot of it is straight forward – I will simply link to the entire java class and show some selective snippets below. For starters, this class was created using layouts with the LatticeLayout layout manager (Update: Site is down, old lik was here, I’ve changed link to the direct jar download which contains javadoc and sources as well), so if you don’t want to re-code those sections, go grab it. (This is a simpler MigLayout layout manager) similar to Swing’s TableLayout. Should you not wish to use either, it should be easy to change the layouts to anything you want (GridLayout for example).

You can download the Java file here (and at the bottom of the article). I suggest you browse through it quickly before we continue as it will make it much easier to follow. Do note that this class has been optimized to “fit in one class”, as normally some of the methods found in there would undoubtedly be split up into other places. But for the making this article it was combined into one file.

Using Preferences

Normally in a RCP application we would be using an IPreferenceStore to save/load our preferences. But as we need to save the location of what workspace we used last – before we have access our preference store (which is saved in our not-yet-selected workspace location), we need to save/load from somewhere else. The most logical solution is to use the java Preferences API. By defining a preference location along the lines of;

// create/get our preferences location based on the class
private static Preferences _preferences = Preferences.userNodeForPackage(PickWorkspaceDialog.class);

// lets define the keys we will be saving
private static final String _KeyWorkspaceRootDir   = "wsRootDir";
private static final String _KeyRememberWorkspace  = "wsRemember";
private static final String _KeyLastUsedWorkspaces = "wsLastUsedWorkspaces";

we can now save/load those preferences as early or late as we want. Do note that any user launching the application on the same computer will be seeing the same saved preferences, so if you need a more secure or private solution this may not be ideal for you. But for 99% of us this is fine. If you do not know how the Java Preferences API works, take a quick look at the API or the PickWorkspaceDialog.java file.

Identifying Our Workspace

When a user selects a directory, we want to check if that directory is a “Our Application” workspace directory or some other plain directory. We do this by creating an empty file when the workspace is created, so that later, if they select an existing directory, we can say if it’s a valid “Our Application” workspace directory or not. In the PickWorkspaceDialog.java class you will see a method named checkWorkspaceDirectory that deals with both checking if a directory already exists or not (to ask if the user wants to create a new workspace there), and it also deals with checking any existing directory to ensure it’s a workspace directory for our application. The filename is defined at the top of the class, just look for public static final String WS_IDENTIFIER = ".our_rcp_workspace";

You will also see code that checks to ensure the user doesn’t select a subdirectory of an existing workspace directory, as that could cause an infinite recursive directory-creating loop, which is obviously bad.

Running the code from within RCP will give you a dialog that looks like this (assuming you gave it a nice image to display – the wizard image used in the screenshot is part of the Eclipse platform, so you can find most of them inside the eclipse jars):

As we need to hook it up to actual code, showing the screenshot before we do so makes it easier when I mention things as the “remember” checkbox.

Hooking It Up

Back in Application.java we now want to change our previous code to use the dialog to ask the user for a workspace. We also need to check if the user selected the “remember” checkbox as then we don’t show the dialog at all (unless the previously selected workspace directory can’t be found). We also want to check that the old workspace directory is still OK in terms of reading/writing etc. All in all, we want something like this (excuse the formatting, the sourcecode formatter doesn’t like large deeply nested blocks):

public Object start(IApplicationContext context) throws Exception {
	try {
		// the old Eclipse generated code
		Display display = PlatformUI.createDisplay();
		// and so on..

		// get what the user last said about remembering the workspace location
		boolean remember = PickWorkspaceDialog.isRememberWorkspace();

		// get the last used workspace location
		String lastUsedWs = PickWorkspaceDialog.getLastSetWorkspaceDirectory();

		// if we have a "remember" but no last used workspace, it's not much to remember
		if (remember && (lastUsedWs == null || lastUsedWs.length() == 0)) {
		    remember = false;
		}

		// check to ensure the workspace location is still OK
		if (remember) {
		    // if there's any problem whatsoever with the workspace, force a dialog which in its turn will tell them what's bad
		    String ret = PickWorkspaceDialog.checkWorkspaceDirectory(Display.getDefault().getActiveShell(), lastUsedWs, false, false);
		    if (ret != null) {
			remember = false;
		    }

		}

		// if we don't remember the workspace, show the dialog
		if (!remember) {
		    PickWorkspaceDialog pwd = new PickWorkspaceDialog(false);
		    int pick = pwd.open();

		    // if the user cancelled, we can't do anything as we need a workspace, so in this case, we tell them and exit
		    if (pick == Window.CANCEL) {
			if (pwd.getSelectedWorkspaceLocation()  == null) {
			    MessageDialog.openError(display.getActiveShell(), "Error",
				    "The application can not start without a workspace root and will now exit.");
			    try {
				PlatformUI.getWorkbench().close();
			    } catch (Exception err) {

			    }
			    System.exit(0);
			    return IApplication.EXIT_OK;
			}
		    }
		    else {
			// tell Eclipse what the selected location was and continue
			instanceLoc.set(new URL("file", null, pwd.getSelectedWorkspaceLocation()), false);
		    }
		}
		else {
		    // set the last used location and continue
		    instanceLoc.set(new URL("file", null, lastUsedWs), false);
		}	

		// this is the normal default code from here on out
		int returnCode = PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
		if (returnCode == PlatformUI.RETURN_RESTART) { return IApplication.EXIT_RESTART; }
		return IApplication.EXIT_OK;

	}
	catch (Exception err) {
		...
	}
	finally {
	    display.dispose();
	}
}

And that’s it. We now have a fully working and modifiable “Select Workspace” dialog that tells Eclipse where to put the metadata and we can modify any of it to our hearts content. With that all out of the way, the only thing remaining is the “Switch Workspace” action.

Switch Workspace

Eclipse has a built-in Switch Workspace action that you could access from the ActionFactory, but as we custom implemented our workspace picker, this wouldn’t help us much. Our dialog is already set up to handle a workspace switch (pretty much all it does is show a different message after all).

So, lets create an Action that will be our Switch Workspace action. It will be surprisingly short, and look like this:

public class ActionSwitchWorkspace extends Action {

    private Image _titleImage;

    public ActionSwitchWorkspace(Image titleImage) {
        super("Switch Workspace");
        _titleImage = titleImage;
    }

    @Override
    public void run() {
        PickWorkspaceDialog pwd = new PickWorkspaceDialog(true, _titleImage);
        int pick = pwd.open();
        if (pick == Dialog.CANCEL)
            return;

        MessageDialog.openInformation(Display.getDefault().getActiveShell(), "Switch Workspace", "The client will now restart with the new workspace");

        // restart client
        PlatformUI.getWorkbench().restart();
    }
}

As all necessary variables and workspace locations are handled in the PickWorkspaceDialog class we don’t need to do anything else than tell the picked that it is now a “Switch Workspace” dialog, and then restart the RCP application if the user pressed “OK”.

Ideally we’d add this action in our ActionBarAdvisor class (default name is ApplicationActionBarAdvisor) under the File menu somewhere.

The result when run will look like this:

That’s It

With the code mentioned in this article you now have full “workspace” functionality for your Eclipse RCP application without having to dig in to extension points or other XML-based overrides, and you have the ability to customize any of it as much as you want. As you see it doesn’t take that much code as most of the big code is methods for copying files and checking directories.

All Code

Here are download links to all code referenced in this article:

(For the Application.java code please copy the big block in the article as it shows all code related to that class.)

Glazed Lists is an API built on top of java.util.List which adds a notification framework and allows you to “stack” or “chain” lists together. This in and by itself may not sound so exciting. What this gives you though is the ability to take a Sorted list, stack it with a Filtered list, stack it with a Unique list, stack it with a asynchronously updated Unique list (and keep stacking), and whenever you modify the source list, it automatically tells the other lists in the chain to update so that their lists are always up to date. Last but not least, the list reports back to you and tells you to update your view with a specific list of changes. So imagine this “chained list” is the input for your TableViewer and perhaps you’re starting to see the potential.

I’ve been using Glazed Lists continuously for the last year, and it’s no short of astounding how powerful it is. I’ve used them on JFace TableViewers, The Nebula Grid widget, and the great rising-star NatTable which deserves it’s own article down the road (the only table widget I’ve found that can handle huge amounts of data without choking). On each of those widgets it was only a matter of creating a couple of smaller classes, a few lines of code, and I had the most powerful sorting and filtering API at my fingertips, ready for anything upper management could throw at me in terms of features. So often I see posts on the Eclipse Newsgroups asking about multi column sorting, and usually few concrete replies. “Glazed Lists” would be my reply.  To give an idea of what kind of sorting/filtering you can do, here’s a snapshot of  some of the available list types:

Sorted List. Filtered List. Unique List. Transformed List. Range List. Threshold List. Collection List. Freezable List. Popularity List. Separator List. Sequence List. Transaction List. Observable Lists.. and the list goes on.

So instead of talking about how great they are in an entire post, how about some example implementations and actual code? Alright, let’s get to it!

To make this article “worth it” for everyone, I will cover implementing Glazed Lists on no less than 3 table/grid widgets. The standard JFace TableViewer (which is the least feature rich table component out there as it uses the SWT Table). The Nebula Grid widget (which is feature rich and very good, but has a big memory footprint on large tables) and the NatTable widget (as it will undoubtedly rise to fame soon with the next few versions (once some of the bigger bugs are ironed out)). Before you start copying and pasting code, all code is downloadable in each respective section and at the bottom of the article.

If you prefer to follow along or want to get a head start on downloading required jars, here are links to all the third party packages you might need:

Let’s start with the basics of Glazed Lists, as everything starts there.

Glazed Lists In a Nutshell

I could send you to the Glazed Lists Tutorials and tell you to follow those and come back, but I hate that kind of “teaching”, and the small “problem” with the tutorials is that they are all Java Swing based which is of little use to us (but by all means read them, they’re good). You might also want to check out the very good screen casts located here as they will give you a good idea of the different types of lists that can be used in Glazed Lists. In any case, everything in Glazed Lists starts with one thing, the root list. The root list contains all your items that you want to display before they are filtered or sorted. This list is probably in some random you-don’t-care order  which is perfectly fine. This list will serve as the input for all other chained lists. Think of it as layers, where the bottom layer is the raw list, and the higher up you go, the more refined and specific each layer is. So you have a sorting layer, a filter layer, etc. They can be active or not active, a bit like Photoshop. As we are using Glazed Lists, we need to take our root list and turn it into a Glazed Lists “EventList”, which is the Glazed Lists root-list equivalent. Here’s how that’s done:

List<?> rootList = .... // this comes from you
EventList<?> eventList = GlazedLists.eventList(rootList);

As you can see everything uses Generics, just like normal Lists in Java 5+.

Any “normal” table in the UI-world will undoubtedly have Sorting and Filtering. With the code above we’re currently no different from any other plain old table implementation as we haven’t done sorting/filtering yet. So lets create the sorting/filtering layers that will be on top of the event list. We should think about order when it comes to our layers, as if we create a sorted list on top of a filtered list that’s not the same as creating a filtered list on top of a sorted list. Logically, we sort first, then apply a filter. To create our new lists we continue the code:

List<?> rootList = .... // this comes from you
EventList<?> eventList = GlazedLists.eventList(rootList);
SortedList sortedList = new SortedList(eventList, null);
FilterList(sortedList, new OurFilterMatcher());

As you can see we keep using the last list as the input for the new list, as that’s our “chain”. The second parameter for the SortedList is the Comparator we want to use when sorting. I’m passing in null here to point out that it can be created when constructing the list (and not passing in null may actually throw an exception). Normally you don’t want the table sorted unless the user sorts it, so null makes sense. The OurFilterMatcher will be explained when we do the actual implementation, but just remember that it’s the “Matcher” that is used to filter a table (which is very much like a ViewerFilter).

There’s one more important aspect of Glazed Lists – locking. As lists can be updated on multiple threads (if you so wish) you need to tell the list when to “lock” and “unlock” so that only 1 thread is actively writing to the list at the same time. As such, it’s important we always do this when reading and writing to the list (and even if we don’t plan on multithread updates, it’s still good practice and takes little time to do). We could lock the lists when creating them even, but that’s a bit overkill, so keep en eye out for the locking code in the implementation part and in the framework code available for download. Glazed Lists even supports reading while writing, and their homepage has an example of an asynchronously updated list. Do check it out if you need advanced implementations. To give a quick example of locking/unlocking a list, here’s how it’s done:

_eventList.getReadWriteLock().writeLock().lock();
// ... modify list here ...
_eventList.getReadWriteLock().writeLock().unlock();

The Callbacks

The whole idea of Glazed Lists is that when you modify the event list (and this is important: you always modify the EventList!), it fires events to tell you what you need to change in your table implementation. Glazed has a lot of pre-built hooks for Swing, so there you don’t have to do much work, but as we use SWT we have to do pretty much all the work ourselves (great huh?). It’s not as bad as it sounds however. The callback interface that we care about here is ListEventListener which contains a method callback called public void listChanged(ListEvent<?> listChanges). This list of changes listChanges tells us, in the correct order, what indexes and objects to update, delete and insert. It’s as easy as looping through that list, checking what the change is, and performing it. Here’s a barebones example of how it would look implemented:

_filterList.addListEventListener(new ListEventListener<?>() {

	@Override
	public void listChanged(ListEvent<?> listChanges) {
		// get the list of changes (prior to looping, very important as it'll change as it's read)
		final List<?> changeList = listChanges.getSourceList();

		// go through all changes
		while (listChanges.next()) {
			// get the table index location of the change
			int sourceIndex = listChanges.getIndex();
			// get the change type
			int changeType = listChanges.getType();

			// update the table depending on the change type
			switch (changeType) {
				case ListEvent.DELETE:
					// delete row
					break;
				case ListEvent.INSERT:
					// insert row
					break;
				case ListEvent.UPDATE:
					// refresh row labels etc
					break;

			}
		}
	}

});

That’s actually the most complex code we’ll be adding to make all of this work, and we can re-use that section of code for all our table widget implementations.

You might ask “why is the listener on the filter list if we were told to only modify the event list?”, which is a good and valid question. The answer is that if you were to listen on the event list instead, only base-level adds and deletes would be reported to you. As we also care about when stuff is re-ordered or moved in the list (which is what happens when users sort and filter) we want any list-changes to notify us. As our filtered list is the “topmost” or “last” list in the chain, it will get all notifications from all previous lists in the chain. Remember, all lists in the chain tell the next list down the line what changed (think of it as one-way gossip). By listening on the Filtered list we get all events, regardless on what list they happened. With that information we’re well on our way to putting Glazed into real use.

SWT TableViewer

Personally I was never a big fan of the SWT Table. A good thing about it is that it renders column headers natively, but it can be quite slow, sometimes buggy (first-column image support) and not very intuitive. It doesn’t support much customization and the second you need a table that can do a little more than a plain x/y grid, you soon hit those limitations head on. Owner Draw does help, but there’s still a lot of customization that is not possible. That said, as a “basic table” it does just fine and it’s getting better for each new SWT version. And of course, it’s native.

Normally when someone asks “can I sort a SWT.VIRTUAL table?” the answer is no or “not really”. The reason is that a virtual table only really knows what it shows in the current viewport (the visual area of the table), and how many items it has. Anything that you can’t see is not really “there”, except in memory. This obviously makes such a useful feature as SWT.VIRTUAL fairly useless in a sort scenario. The workaround in that case is to custom implement a sorter and replace the entire table content whenever the user sorts or filters. As we use Glazed Lists we don’t really care about this limitation, we’re working around it as we update the table with our changes whenever they occur thanks to the callback from Glazed Lists.

There’s a few special things we need apart from a “normal” Virtual TableViewer implementation. First, we’ll be using the IStructuredContentProvider for the Content provider. The ILazyContentProvider exists as well, but I had some odd issues with it in testing. If you want an example on how to create a virtual TableViewer, there’s a good snippet here: Snippet029VirtualTableViewer. In the IStructuredContentProvider we simply return the topmost layer (which is the FilterList) as follows;

class GlazedContentProvider implements IStructuredContentProvider {

	@Override
	public Object[] getElements(Object inputElement) {
		return _filterList.toArray();
	}

	@Override
	public void dispose() {
	}

	@Override
	public void inputChanged(Viewer viewer, Object oldInput, Object newInput) {
	}

}

We also need to implement a Comparator which will be used by the SortedList, as well as a Matcher for the FilterList. The Comparator is a normal java Comparator whereas the Matcher is a Glazed Lists implementation. However, these are immutable so they need to be new every time they are set on the respective lists. For the sake of simplicity, lets create an object called RowObject that represents one row in our table. All it does is keep track of the row number and it has a getColumnText method.

class RowObject {
	private int	_row;

	public RowObject(int row) {
		_row = row;
	}

	public int getRow() {
		return _row;
	}

	public String getColumnText(int col) {
		return "" + (_row + col);
	}
}

With this all set up, we can now create the Comparator and Matcher. Lets start with the Comparator. As we’re basically returning an integer as display value for each cell in getColumnText we’ll use this as the basis for our comparison. Thus, our Comparator looks as follows;

class GlazedSortComparator implements Comparator<RowObject> {

	private int	_col;
	private int	_direction;

	public GlazedSortComparator(int col, int direction) {
		_col = col;
		_direction = direction;
	}

	@Override
	public int compare(RowObject o1, RowObject o2) {
		int ret = Integer.valueOf(o1.getColumnText(_col)).compareTo(Integer.valueOf(o2.getColumnText(_col)));

		if (_direction == SWT.DOWN)
			ret = -ret;

		return ret;
	}

}

And now we create the Matcher which is used by the FilterList. The Matcher implementation in Glazed Lists asks us if a row object “matches” and not much more. This may seem confusing at first, but it’s quite similar to the ViewerFilter. In our code we will have a textbox and a button that represents a “search” box. When the user presses the button we set a String field called “_filterText” to whatever the user entered, and then we set a new matcher on the FilterList. As such, our code implementation looks like this:

class GlazedMatcher implements Matcher<RowObject> {
	@Override
	public boolean matches(RowObject row) {
		for (int i = 0; i < _table.getColumnCount(); i++) {
			if (row.getColumnText(i).indexOf(_filterText) > -1)
				return true;
		}

		return false;
	}
}

Now we can add two methods that actually do the updating when we filter and when we sort. Like this:

// update the table filter
private void updateFilter() {
	// if the search text is blank, remove the matcher
	if (_filterText == null || _filterText.length() == 0) {
		_filterList.setMatcher(null);
	}
	else {
		_filterList.setMatcher(new GlazedMatcher());
	}
}

// sorts a table on the given column
private void sortColumn(int col) {
	// do some normal UP/DOWN checking and updating
	int dir = SWT.UP;
	int current = _table.getSortDirection();

	TableColumn tc = _table.getColumn(col);
	if (_table.getSortColumn() == tc) {
		dir = (current == SWT.UP ? SWT.DOWN : SWT.UP);
	}

	_table.setSortColumn(tc);
	_table.setSortDirection(dir);

	// now tell the sorted list we've updated
	_sortedList.setComparator(new GlazedSortComparator(col, dir));
}

At this point we’re basically there. All that’s missing is a proper listChanged that reflects how we update a TableViewer. So with a few modifications to the code I posted in the nutshell section, we get code that looks like this:

_filterList.addListEventListener(new ListEventListener<RowObject>() {

	@Override
	public void listChanged(ListEvent<RowObject> listChanges) {
		try {
			_table.setRedraw(false);

			// get the list PRIOR to looping, otherwise it won't be the same list as it's modified continuously
			final List<RowObject> changeList = listChanges.getSourceList();

			while (listChanges.next()) {
				int sourceIndex = listChanges.getIndex();
				int changeType = listChanges.getType();

				switch (changeType) {
					case ListEvent.DELETE:
						// note the remove of the object fetched from the event list here, we need to remove by index which the viewer does not support
						// and we're removing the object index location from the event list, not the filtered list
						_viewer.remove(_eventList.get(sourceIndex));
						break;
					case ListEvent.INSERT:
						final RowObject obj = changeList.get(sourceIndex);
						_viewer.insert(obj, sourceIndex);
						_viewer.replace(_filterList.get(sourceIndex), sourceIndex);
						break;
					case ListEvent.UPDATE:
						_viewer.replace(_filterList.get(sourceIndex), sourceIndex);
						break;
				}
			}

			// most important, we update the table size after the update
			_viewer.setItemCount(_filterList.size());
		}
		catch (Exception err) {
			err.printStackTrace();
		}
		finally {
			_table.setRedraw(true);
		}
	}

});

The result, when combined with the rest of the necessary boilerplate code, looks like this:

Download Code

TableViewerGlazedExample.java

Nebula Grid

Whereas the normal SWT table only supports single column sort (unless you owner draw) the Nebula grid can do more. It can do multiple column sorting (visually), grouped columns, and other custom features not available in the default grid. The Nebula Grid has a Viewer implementation, but unfortunately at the time of writing this article, it does not support SWT.VIRTUAL mode. As Nebula sticks very much to the SWT API in terms of naming conventions and implementation, it should be little trouble to convert it over when it does.

Depending on how you look at it, you are about to get quite lucky. For my job I wrote an entire framework implementation wrapping Glazed Lists in a Nebula Grid. It’s much more generically implemented (with interfaces etc) than our TableViewer example which was written purely for this article. Because of this I don’t feel like actually ripping it apart into something smaller, so I will use this Framework as the basis for the examples. Thus, this implementation comes with the option to use both the GridViewer implementation (which might be good if you are doing smaller tables that don’t need Virtual mode) or the grid in SWT.VIRTUAL mode.

One of the bigger differences when we’re not in viewer mode, is that on the DELETE, INSERT and UPDATE we need to create GridItems instead of just telling the viewer that it’s changed. It’s a bit more clunky and object-heavy of course, but it’s not as bad as it sounds. The switch statement that we used in the previous example becomes this:

switch (changeType) {
    case ListEvent.DELETE:
        removeItem(sourceIndex);
        break;
    case ListEvent.INSERT:
        final IDataObject insert = list.get(sourceIndex);
        addItem(insert, sourceIndex);
        break;
    case ListEvent.UPDATE:
        final IDataObject update = list.get(sourceIndex);
        removeItem(sourceIndex);
        addItem(update, sourceIndex);
        break;
}

As you can see each one calls a sub-method of the class, and those methods look like this:

private void removeItem(int index) {
	_parent.getTableViewer().remove(_parent.getTableViewer().getElementAt(index));
}

private void addItem(IDataObject msg, int index) {
	GridItem gi = new GridItem(_parent.getGrid(), SWT.NONE, index);
	gi.setData(msg);

	try {
		for (int i = 0; i < _parent.getGrid().getColumnCount(); i++) {
			Color fg = msg.getForeground(i, index % 2 == 0);
			Color bg = msg.getBackground(i, index % 2 == 0);
			Font f = msg.getFont(i);
			String txt = msg.getColumnText(i);
			Image image = msg.getColumnImage(i);

			if (fg != null) {
				gi.setForeground(i, fg);
			}
			if (bg != null) {
				gi.setBackground(i, bg);
			}
			if (f != null) {
				gi.setFont(i, f);
			}
			if (txt != null) {
				gi.setText(i, txt);
			}
			if (image != null) {
				gi.setImage(i, image);
			}
		}
	}
	catch (Exception err) {
		err.printStackTrace();
	}
}

In this code we use an interface IDataObject that is basically our RowObject code from before. This object has various getter methods for returning column texts, images, fonts and so on.

So how do we go about creating a Nebula Grid based grid with this framework? Mostly it’s the same way it’s done with pretty much any SWT widget, along the lines of:

GlazedGridViewer viewer = new GlazedGridViewer(shell, SWT.V_SCROLL | SWT.H_SCROLL | SWT.MULTI | SWT.VIRTUAL, this, true, null, null, false);
viewer.setAllowMultiColumnSort(true);
viewer.getGrid().setCellSelectionEnabled(true);

Some pointers: The this parameter is an interface implementation of IGenericGridTable which forces the implementor of the code to include methods for returning a Comparator and a Matcher, like we created before in the previous example. true is the option to create the grid as a plain grid, or to false to create a viewer. The last 3 parameters are a String id used for saving/loading the table state (column order, sizes etc), an IPreferenceStore where it would be saved on, and lastly a true/false whether the table should be saving the state at all.

The framework comes with a default implementation of a Label provider and a Content provider which hooks into the IDataObject. They are created automatically depending on the table type you picked. Column creation is also handled by the framework as the column wrapping implementation allows for individual setting of if a column is sortable, movable, hide-able etc. The API looks like:

public GridViewerColumn(IGlazedGridViewer parentTable, String name, boolean frozen, boolean moveable, boolean sortable, boolean hideable) {
     ...
}

But when you create a column you do it via the framework as:

GridViewerColumn col = viewer.addColumn(str, false, true, true, true);
col.getGridColumn().setWidth(100);

And finally, to add objects and set the table input, it’s again much like the TableViewer, for example:

List<IDataObject> input = new ArrayList<IDataObject>();
for (int i = 0; i < 1000; i++) {
	input.add(new OurIDataObjectClass(i));
}
viewer.setInput(input);

I don’t think much more needs to be said about the framework. It has a lot of API in it already and a test class as well. I suggest you download it if you want to give it a go.

Important: as I currently am not using the framework due to the fact that the Nebula Grid was too slow and memory hungry for what we needed it for (40,000+ rows) I converted the entire framework over to use a NatTable and kept the work going from there. It should be fine, but there may be some minor issues here and there as it was never fully tested. If you find problems and fix them, do send me the code so that everyone can benefit. For the NatTable implementation of the framework, that’s the next section of this article.

All put together, the test code looks like this when run (with shameless self-promo selection):

No filter box in this example, but I think the TableViewer one shows how it works so it’s not necessary. A point worth making though is that all filters are DataFilter based (framework class). That class extends ViewerFilter so that if you need more than one table implementation, you can re-use your filters should you so wish. That filter also comes with “whole word”, “regular expression” and “case sensitive” filter/search options in the filter itself.

Download Code

Glazed Lists – Nebula Grid Framework

Nat Table

The NatTable Widget (Nat stands for Natalie, the girlfriend of the original widget author) is a fairly new Grid widget and one that I personally was quite impressed with after having researched pretty much all SWT grid widgets out there. It’s still in active development, and not everything is working 100% yet (grouped columns are problematic, some random drawing issues, frozen columns behave oddly, listeners are quite messy), but overall it’s in a good enough shape that we decided to use it in production. The reason I decided we should use it was simple; We needed a table that could deal with 40,000+ rows in 20+ columns without any lag or any drawing slowdowns whatsoever. It needed to be customizable and I wanted Glazed Lists on it. NatTable is inherently virtual, so you don’t tell it that it’s virtual, it just is. It only draws what you see in the viewport which makes redraws near instant and the overall feel is “snappy”.

The NatTable API is also quite different from most SWT widgets. Pretty much every part of the table can be extended or implemented in a custom way, and there’s a lot of classes and places to do this in. At the same time, the API feels sometimes half-finished as simple methods such as selectAll() are nowhere to be found, and trying to figure out how to do it can be a bit of a head-scratcher. So, It takes a while to wrap your head around the API, but with help from a few examples on their homepage it shouldn’t be too much of a deal (and most of those kinds of methods are in the framework). The table is model driven, which I suppose is the third type of table model I see used in tables (first being no model and row-item based, second being a viewer on top of a row-item based grid).

All that said, I truly hope the current development team keeps this widget going (and from the looks of it it’s very active), because it just might be the best SWT grid-table currently out there. The Nebula Grid had huge potential, but development on it is slow going. I know Tom Shindl is doing work on it, but I don’t know what the roadmap is.

Ok, lets get going with the framework I’ve built for NatTable. It’s not complete, just like the Nebula Grid framework which it is based on, but it will get you a very long way. As this framework has gotten further it has more utility methods and automation than it’s predecessor. It will even mimic the Windows column headers through a custom header drawer if so desired. It also has full color-customization support via interfaces and so on. It would be a long list if I wrote it all here, so I suggest you check out the API.

To create a table using the framework, you can use various constructors, of which the biggest is:

public GlazedNatGridViewer(Composite parent, int style, IGenericNatGridTable generic, String tableId, IPreferenceStore store, boolean allowStateSaving, AbstractGlazedNatVisualConfig config) {
       ...
}

You will notice the IGenericNatGridTable is the same interface as in the Nebula Grid framework and works the same way (just different name). The last parameter, AbstractGlazedNatVisualConfig is if you want to pass in custom settings for colors, fonts, widths, heights etc. A whole load of things can be customized, or you can stick to the defaults (DefaultGlazedNatVisualConfig).

In our test class we will do the same as we’ve done in the previous examples, we’ll create some columns, some row data and do a sort. Using the framework we create a new table as follows:

GlazedNatGridViewer viewer = new GlazedNatGridViewer(shell, SWT.V_SCROLL | SWT.H_SCROLL | SWT.BORDER | SWT.FULL_SELECTION, this, new DefaultGlazedNatVisualConfig());
viewer.setAllowMultiColumnSort(true);

for (int i = 0; i < 10; i++) {
	NatGridViewerColumn col = viewer.addColumn("Column "+i, false, true, true, true);
	col.setDefaultWidth(100);
}

List<OneRow> input = new ArrayList<OneRow>();
for (int i = 0; i < 1000; i++) {
	input.add(new OneRow(i));
}

viewer.setInput(input);

Our OneRow class implements IDataObject which contains getters for all things table related (column text etc). It also contains a getter specifically for returning a value that should be used when comparing column data when sorting. By default we simply return the same column text as the visible-to-user text:

class OneRow implements IDataObject {

	private int _row;

	public OneRow(int row) {
		_row = row;
	}

	@Override
	public String getColumnText(int column) {
		return ""+(_row+column);
	}

	@Override
	public String getSearchMatchText(int column) {
		return getColumnText(column);
	}

	...
}

The multi column sort feature is already built in, and uses Glazed Lists ability to chain comparators. So whenever you sort more than one column, it will ask for a Comparator for each sorted column, and combine them in the order that you sorted the columns. You multi-sort by holding down the shift key to add more columns, and I’ve also added so it draws a number on the column header for displaying which order it was sorted in. The sort happens as soon as you let go of the shift key (and you can modify the columns by pressing the shift key again before clicking the column header).

Running the test class we get a table that looks like this:

That pretty much sums it up for the Nat Table. Regardless of what table implementation you are going with or decide to go with, I’m sure you will agree that the power and simplicity of Glazed Lists is amazing. And we’ve only scratched the surface on it here. For much more information and examples with deeper complexity I suggest visiting the homepage and checking the Glazed Lists API. They have some built-in support for SWT as well (such as putting your updates on the UI thread), so they’re not 100% Swing-based even though most of their pre-implemented table-realted items are for Swing components.

Download Code

Glazed Lists – Nat Table Framework

Closing words

This was a long article. It took me 2 full days to write and much longer if you count the hours put into creating both frameworks. My hopes is that you will find the article and Glazed Lists useful in your future table and grid implementations, and that this wonderful package becomes as part of your projects as MigLayout or other “must have” API’s that make our lives coding UI’s much easier. Personally I cannot live without Glazed Lists, and I only wish I had found out about them sooner.

And again, I highly recommend the screen casts for more information on each type of list you can create.

Do let me know if you spot errors in the article, it’s hard to cover everything on the first try. I will put these files + a link to this post into the Projects section later as well.

All Code

Here are download links to all code referenced in this article:

Having worked in many companies over the years there are a few things I know better than my managers, and the longer I’m in this business the more frustrated I get when things are simply not working the way they should due to bad management. If I as a senior programmer have to step in to do actual project management because my technical project manager fails to do it, something is wrong. Unfortunately this is more common than it should be. A big issue is that managers that are put in charge of development teams are often under-educated when it comes to development and the development process. In fact, they may know nothing about programming at all, and they’re thrown into a world of developers who can build them anything they request – assuming upper management has a good plan on what needs to be built.

Why and how these managers end up in a technical management positions is always the question, but any programmer who’s been around for a while can usually sniff out the bad ones in mere seconds. A good manager is a mediator, someone who knows they may not always know better, but listens to their team, suggests solutions based on what the team has told them and mediates between the dev team and the rest of the company (and upper management). A good manager could be compared to a good army commander. The troops know they can trust them, and will follow them into battle knowing that all decisions are calculated and weighed and probably the best ones. A bad manager however is one who undoubtedly will cause massive team issues and communication breakdown. In the troop scenario the team would undoubtedly get into serious trouble, and if it were a pirate ship, mutiny would soon ensue.

Down the road bad management leads to anger and frustration, and ultimately to the dark side. I’ve been in many meetings where the programming team starts talking tech issues and the manager sits silently like a question mark watching a tennis match because they have no idea what people are talking about. This is very bad, and a sign of probable project failure down the road (or lots of code re-writes due to miscommunicated features). It’s OK to not understand everything, but if you manage programmers (especially experienced programmers) you need to be someone who understands the field, and understands it well. A developer who knows that their manager does not understand what they tell them will start communicating less and less, and in the end will probably stop altogether as it does not help them in any way. This leads to a team that is disconnected from management, and undoubtedly a manager who has no clue about the status of the project.

Another issue, seemingly common, is that the product manager (who is literally in charge of the product and the outcome thereof) does not even know what the product is. This usually leads to constant feature changes, and a very angry team. A lot of this can be solved with a good specification early on, but with deadlines looming and budgets shrinking, tech specs are a dying breed.

There was a great thread on Slashdot a few weeks back called “Managing Seasoned Developers” which is the basis for this post, and despite the random seasoning jokes, there is some really great information in there. As I don’t expect you to go through that thread to dig out the good stuff, I decided to take the best parts and make a list of “What a good development team manager should and should not do”. I also added a few other worthy entries from other places and adjusted some to reflect my own experiences.

How to deal with experienced developers as a manager (in random order):

It’s also worth mentioning that managers need to be told some of these things (their weak spots), so don’t be afraid to put your foot down, it just might make them better!