Eclipse Debugger Gripes

Since I switched to using Eclipse for my Java developer I also switched to use its built in debugger. In the past I’ve used JSwat, which is a great open source Java debugger, but I’ve had some troubles with recent versions with getting it to pick up my source path. This made the switch easier.

Having your debugger integrated with your editor is great, but so far I haven’t played with hotswapping. I’m debugging everything in isolation with JUnit, which makes tracking down bugs a lot quicker.

But this article is called ‘Eclipse Debugger Gripes’, so here are the moans: ;)

Variable Names DisappearNo variable names in Eclipse Debugger

Every so often, normally as I’m just about to track down a tricky bug, all the variable name information disappears. See the screen shot to see what I’m talking about. You can see the variable values, but you don’t know what the value is for. The only way to fix this is to restart Eclipse. Easy fix but annoying.

At first I thought it was the Sun JVM not playing nice with IBM’s IDE, so I switched to their JVM. Initially it seemed better, but every now and again the names disappear. I have no idea what this is the case, but it’s very annoying.

Jad

This isn’t a gripe about Eclipse so much but JadClipse. It has the option to synchronize the lines of the decompiled file with the line information in the class. This allows you to set breakpoints in binaries. Very useful, but doesn’t always work, sometimes it just doesn’t sync them up. This is where the problem with Eclipse comes in, it only allows you to set a breakpoint by highlighting the line in editor that contains the source, you can’t set one manually. So if Jad can’t create a source file where the lines don’t match up, I can’t set a breakpoint.

Source Paths

I came across this one when Jad wouldn’t do its thing. You can assign a source path to each library you import. But this only takes affect after you restart Eclipse. I thought it was broken and almost started tearing out my hair when it wouldn’t stop bringing up the incorrect decompiled source. A restart corrected this. I’m including this one to save others of this grief.

Otherwise, if you’re using Eclipse and haven’t already, I highly recommend you give the debugger a go.

Spread the word: Technorati related  |  Technorati related  |  del.icio.us bookmark it!  |  submit Eclipse Debugger Gripes digg.com digg it!  |  reddit reddit!

6 Responses to “Eclipse Debugger Gripes”

  1. John says:

    The thing that drives me crazy is, if I set a breakpoint (when debugging code in a WAS test server), the first time it is accessed since the server was started, ClassLoader comes up in the debugger instead of my code-under-test. I let it proceed with F8, and the next time it’s fine.

  2. John says:

    (Oops - yes, obviously, I’m using RSA, not Eclipse)

  3. Carfield Yim says:

    About problem cause by jad, may be you can try to workaround with a pure java decompiler? http://blog.technoetic.com/jode-eclipse-plugin/

  4. Miles says:

    I hadn’t heard about Jode before. It shouldn’t make a difference what language the decompiler is written in, but I’ll give Jode a go to see if it’s better at handling those tricky classes.

  5. JD says:

    Have you filed bugs?

  6. Miles says:

    I haven’t actually. I need to take some notes and see if I can create a reproducible situation. Don’t want them to be closed with a ‘Works for Me’. ;)

Leave a Reply

Line and paragraph breaks automatic.
XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>