Which Java debugger do *you* use

Question

I spend a lot of time debugging applications in Eclipse using JPDA. There are a few issues with the Eclipse debugger which really annoy me. Can anybody recommend plug-ins, better debuggers or perhaps tricks that I don't know of yet?

• In the "Variables" tab, you can type in and execute bits of Java code. However, you first need to click on something (I usually click on "this") to give it some context. Then, after you've typed in a lengthy Java expression to debug something and "execute" it, your expression gets replaced with the result, so you need to type it in all over again. Is there some better way, such as a console or something that I'm missing?
• When you're poking through data structures, the presentation in the debugger leaves much to be desired. You see the internal representation of Lists, Maps, StringBuilders etc. What I want to see is what these objects conceptually contain. Is there a way of doing this, perhaps using some other debugger, or an extension or something?
• When an Exception is thrown, is there some way of inspecting the state of the application where the Exception was thrown? Currently I need to set breakpoints just before the Exception occurs and then try to reproduce it.
• When I'm stepping over a line with many statements on it, I can't actually see which of those statements is being executed, except by "stepping in" to each one to see where it takes me.
• If no source code is found, Eclipse just stares blankly at you. You get a helpful screen saying "Class File Editor / Source code not found" which is completely useless. I'd much prefer to be able to step through the bytecodes so I can at least see what is going on. Does anybody know of a Java debugger that does this better than Eclipse?

Aer

possible duplicate of Recomend a (standalone) java debugger – Site

Answer 1

I have been using the Eclipse debugger for a while now and share some of your concerns. However some of the points you mention have been solved/addressed in the Eclipse debugger:

Data structures: The variables view already has the option to show the "logical structure" of lists/sets/arrays etc. There is a button at the top left corner of this view to enable this. You can also add your own custom representations through the Java->Debug->Logical Structures preferences.

Exceptions: The debugger lets you set exception breakpoints (Add Java Exception breakpoint button in the breakpoints view). These breakpoints are triggered when a particular exception is thrown.

Source code: If you install a plugin (Eg. asm byte code plugin http://asm.ow2.org/eclipse/index.html) that has a viewer for bytecode, the debugger will step through the bytecode when source code is missing.

Tralee

Answer 2

I agree with much of what Vilas Jagannath says.

Using the Eclipse debugger Additional points:

1) The Display view. This view allows you to run code in the context of the current stack frame. This allows you to inspect arbitrary bits of code. In some ways it is a little primitive, but it works great as a scratch pad.

4) If you want to go into some method call in a line with a complex expression, you can navigate to that function and then "Run to Line" (Ctrl + R)

5) You can also use step filters to filter classes you don't care about. Right click on the stack frame you don't care about and hit "Filter Type". Make sure you have "Use Step Filters" on. It is the icon with two arrows just to the right of the drop to frame button on the Debug view.

Tippler

Answer 3

I use NetBeans and its debugger.

About your third point (exceptions): I don't think there is any other way to see the state at the point where the exception is thrown. When the exception is thrown out of the method, the stack frame for that method has been discarded - it's lost so that you can't inspect it aferwards.

The NetBeans debugger also doesn't let you step through bytecode, as far as I know.

Soldierly

Answer 4

Here is my answer - the bullets are in the same order as your question bullets:

• There is a better way to do it:
  1. Use the Display view to execute statements.
  2. Write something on the class itself and "Inspect" it (ctrl+shift+I)
• See the small icon in the variables view that says "Show logical structure". It might be what you are looking for.
• You can set a general breakpoint on Exception to catch the exception as it happens - In the exceptions view the J! icon.
• I use ctrl+alt+mouse left click on the method I want to step in, works like a charm!
• You can still use stepping with keys or buttons (see the stack). If you want to see the code, use decompiler.

I believe they still have what to improve but these tips might help you a bit.

Hereof

Answer 5

Ordinarily, I would say eclipse has a better debugger than my preferred IDE, IntelliJ (free edition) For the first four, IntelliJ is perhaps better with breakpoints on exceptions (which allow you to see the state at the point when the exception is thrown), custom renderers for objects types, and persistent expressions (i.e. the expression is re-evaluated each time you change context)

I don't know of any debugger which will step through byte code.

Strong

"IntelliJ is perhaps better with breakpoints on exceptions (which allow you to see the state at the point when the exception is thrown)" - eclipse does that too. – Ethban

Answer 6

When I'm stepping over a line with many statements on it, I can't actually see which of those statements is being executed, except by "stepping in" to each one to see where it takes me.

Select the function you want to step into, and use "Step Into Selection" (I have it on Ctrl-F5, but you can find it on the context menu).

Spelter

Answer 7

As an alternative, you can litter your code with log.debug and System.out.println's, which means you can do whatever you want!

Restriction

Answer 8

For something different than a gui debugger, I have a project called jdiscript that allows you to script the JVM's Java Debugger Interface. I've found it especially useful for troubleshooting thread contention and finding issues that only seem to crop up sporadically under production loads.

Fenner