views:

1187

answers:

2

How does setting breakpoints in Java work? Is it just based on the source file name and line number? Does the class or method name also figure in?

If I have an old version of the source in my debugger and set a breakpoint, the cursor is off when I step through. How far off can it be? Can it go into the wrong method (or even the wrong class if there are more than one class in that file)?

What happens when there are multiple classes of the same name in the JVM (could happen if you have more than one classloader)? Do they all get the breakpoint?

In a web application container, can I set breakpoints for just one web application (and not the others)?

How much of this is IDE specific and how much is determined by the debugging interface that the JVM provides? For example: In Eclipse I can set conditional breakpoints based on the values of variables. Is that just filtering done by Eclipse on an unconditional breakpoint in the JVM?

+6  A: 

There are different kind of breakpoints. Some breakpoints are line-based, some are not. How this affects your actual debugging depends on what your IDE actually does. For example, in Eclipse, if you add a breakpoint in the middle of a method, that will be a line-based breakpoint. If you add a breakpoint on a line containing the signature of a method, that will be a method entry breakpoint.

If the source code you're looking at is not the exact source of the class that is running, a line breakpoint won't be mapped onto the right line of course. So java might not stop at the line you intended, and your IDE indeed could be showing you the wrong method or even wrong class. But a method entry breakpoint will still work (stop at the right moment), even if the line on which the method was defined has changed; but again an IDE might show the wrong line in the debugger. (And there are other kind of events/breakpoints too, like class loading,... You could take a look at the subinterfaces of EventRequest if you want to know more about the internals).

To answer your other question: breakpoints apply to all classloaders in the JVM.

Wouter Coekaerts
+2  A: 

The JVM supports a standard API for debugging (see Java Platform Debugger Architecture), and all IDEs use the JPDA to do all the heavy lifting of setting breakpoints, computing expressions, and so on. The IDEs "just" wrap it up in nice user interfaces.

When you set a breakpoint, the IDE talks to the JVM's Tool Interface (part of JDPA) and gives it the source file and line number of the breakpoint. The JVM has the information it needs to map the physical location of the breakpoint onto the actual location of the Java statement in the compiled code of the class. When the JVM reaches a breakpoint, it stops executing that thread and tells the IDE the breakpoint's source file and line number. The IDE then displays the location to you.

When I debug I sometimes add or delete lines to fix a problem, and then continue on to the next problem. But things get wierd because breakpoints now appear to be sooner or later than I expected, and if I set new breakpoints they're not actually at the source line I set them at. When this happens, I restart the program and then both the IDE and the JVM are consistent again.

Jim Ferrans