How can I set the current line of execution in the eclipse java debugger

Question

I want to force the current execution line to a specific line in the same function. All my old school debuggers had this feature, but I can't find it in eclipse. Is there a way to do it without changing code?

Answer 1

"Run to line" appears to need the program to be running and in a paused state to use. The other option is to set a breakpoint for that line when running in debug-mode.

1. Double-click far-left vertical bar in the source pane on the same line to add a breakpoint; or,
2. Select the line and go to Run > Toggle Breakpoint.

At least, this is in Eclipse 3.3.2.

Answer 2

The first two answers seem to miss the topic, unless it is me not understanding the question.

My understanding, a feature I searched myself, is that you want to skip a number of lines (when stepping in code) and set the program counter (to take assembly vocabulary) to the given line. It might be interesting to skip some costly object creation, see some error situations, etc. I used to do that in Visual Studio (C or C++ code).

I haven't found that in Eclipse, nor in NetBean. It might be a limitation of JVM, or an enforcement of some policy...

The Run to line command execute, of course, all lines between the current execution position and the designated one.

Answer 3

I think that is not possible in Java. The only feature that allows you to "step back" is using "drop to frame", which takes you back to the first instruction of the current frame. At least I haven't seen any debugger with this specific functionality, but I haven't been able to find on the net why is it so...

I know the debugger in Visual C allows to change to pointer. I will keep on searching, maybe at least we will know why is like this, but it seems to be some kind of design limitation.

Answer 4

I too have long sought this feature, and "Run to line" is not the same thing.

This may well be a limitation of the JVM. Java does not implement goto, though it does have jump statements, like break and continue. Those are at the block level however. If this is a JVM limitation, my guess is that it is more likely due to the security architecture. Tight control of the program counter is debilitating for interlopers, like viruses -- and sadly debuggers.