RSE 1.0 M4 released

The Target Management Project has released milestone 4 of its Remote System Explorer (RSE). The RSE is a perspective and toolkit in Eclipse Workbench, that allows you to connect and work with a variety of remote systems. M4 has been found nicely stable already.


What's perhaps most interesting for the average Eclipse user, is a remote file system explorer using the ssh connection type. With it, committers can work on the dev.eclipse.org server just as if it were local - and edit remote files, or use it for uploading.

A remote command shell is also available, providing content assist and output pattern matching for commands like find or grep -n. For generic remote terminal access, the TM project is going to integrate a full-blown terminal emulation in the near future.

Got interested? The RSE works with Eclipse 3.2, or 3.3M1. It is most easily available from our update site at http://download.eclipse.org/dsdp/tm/updates: For a minimal install, choose runtime-core, runtime-local and runtime-ssh. Alternatively, you can also get it from the TM download area. A tutorial will guide you through the first steps. We'll be happy to get your feedback as a bug entry or on the mailing list!

Catch me if you can ?!?

I really like the JDT's Java Exception Breakpoints: Most of the time, I'm running my code from the debugger, with breakpoints set at least on NullPointerException and ClassCastException (through Run > Add Java Exception Breakpoint). It brings my debugger exactly to those places where a problem occurs - and helps me to diagnose it right away.

But sometimes, the debugger breaks at unexpected places, like the following code I've seen the other day:

try {
   FooManager.getFoo().execute();
} catch (NullPointerException e) {
   //Nothing to execute if foo's not there yet
}

Apparently, the original developer's idea was that the FooManager might have a foo or not -- if it doesn't have one, then getFoo() returns null and there is nothing to execute.

Now most seasoned Java Hackers may have it in their guts that this is not good code. The younger ones might know it because Bloch writes it (Effective Java, chapter 8, Item 39: Use exceptions only for exceptional conditions; if you haven't read this book, you must read it!).

Bloch has some good arguments for avoiding exceptions instead of catching them. But using exception breakpoints, here is another just practical one - it breaks the debugger where it's not necessary, because the code does run as intended. So I've changed the code:

Foo foo = FooManager.getFoo();
if (foo!=null) {
   foo.execute();
}

Now that's even shorter (4 lines of code instead of 5), clearer to understand, and my Debugger won't need to get active... so in the future, I'll live with Catch me if you can't avoid me - which might have made the life of Tom Hanks easier too...