A surprising side effect of this runtime check is that it avoids a problem with using Adapters: if you subclass an adapter and you try to override one of its methods, you may actually typo the override method and neither the compiler nor the runtime environment would be able to detect this. With SwtCallback a typo like that would be detected at runtime. (The @overrride tag is another solution to this problem.)

As for refactoring, you’re right. Eclipse wouldn’t be able to rename one of these methods. In practice the callbacks are usually declared in the very same class or possibly in the corresponding view class for a particular controller. In the rare case that you do want to rename a method you would indeed have to suffer changing two different places by hand, but at least the other place you need to change is usually close at hand.

You don’t need to lose the event object. If your callback method signature includes an event parameter, SwtCallback will pass the method the corresponding event object when calling it.

Using an anonymous inner class to call out to a private handler is a good solution which I like too. I still prefer the one line solution of SwtCallback as it’s shorter and less complex: I don’t have to remember that the method I need to override is ‘public void widgetSelected(…)’ in a SelectionAdapter. With an Swtcallback, all I have to do is to select the right SWT.XXX identifier and I’m good to go. Every handler I make will have this consistent syntax.

Thank you for your interesting comments. To summarize: yes, there is no compile time checking of the provided method. On the flip side there’s solid runtime checking. You don’t need to lose the Event object when using SwtCallback. Finally, SwtCallback is easier on the programmer’s memory and less complex than anonymous extended adapters in inner classes, at least in my taste.

That said, Mr. Pryor’s presented solution is a good alternative to SwtCallback, especially if you wish to be able to refactor your handler methods, and you desire a solution that is statically correct instead of being a dynamic runtime solution.

I didn’t look at the code behind this at all, but don’t you also lose the event object with this approach? You don’t always need it but sometimes you do.

Also, the recommended SWT approach is to have anon. inner class methods delegate to an identically named private method in the outer class:

myButton.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(SelectionEvent e) {
MyClass.this.widgetSelected(e);
}
}

private void widgetSelected(SelectionEvent e) {
…
}

You could of course change the private outer class method to something that was named more specifically if you had more than one of these handlers.

To my eyes anyway, the above method is as readable as using the callback library and has the advantage of type safety and refactorability.

Anyways, like I said an interesting approach – I’d enjoy hearing your comments on the above.