Bug 103936

Created attachment 42387 [details]
The textual diff of the API change.

Please review this enhancement of capabilities of JPDA breakpoints.
These are just setters/getters. I'll write test for the correct behavior of the
implementation classes shortly...

Hit counts are a big bread-and-butter of intermediate debugging.
We should also strive to make converge the native and java bpt dialogs
and having a common count UI would be very beneficial.

Has there been any UI study into their use cases? 
For example, why an equals and a greater than? 
I'm also curious whatthe user-case for multiple-of
is. I've seen it in MSVC but could never figure where it comes
handy.

The hardest things to know with bpt counts is actually what to make the
count be. The use-case is typically as follows: 
some NPE or SEGV occurs. 
user wants to stop at a bpt the last time before the segv. 
user sets the btp count to a very high number and runs the app and gets
the NPE or SEGV. The current bpt count is the desired count.

for this dbx and SunStudio has three things:
A distinction between a bpt limit and a bpt count. The bpt fires when
the count hits the limit.
An artificial "infinity" count limit.
An action that assigns the current count to the count limit.

It's true that the hit count is not Java-specific, so we should probably move it
from org.netbeans.api.debugger.jpda.JPDABreakpoint into
org.netbeans.api.debugger.Breakpoint. So that it can be used by all debuggers.

I'm not so sure about the common UI. We could append the GUI components for
setting the hit count into the customizer in
org.netbeans.modules.debugger.ui.actions.AddBreakpointPanel, but I would rather
leave it on individual breakpoint customizers, because it might not fit together
nicely if it would be assembled by debugger core.

Regarding the UI study, I've started with two issues we have for this: issue
#58799 and issue #90141. Then I've searched mailing lists:
http://www.netbeans.org/servlets/ReadMsg?listName=nbusers&msgNo=49778
Unfortunately the serach of mailing lists is too primitive to be able to find
more user reports :-(
Other IDEs mostly add just "Hit Count" field into the breakpoint properties. Like:
http://java.boot.by/icad-guide/ch05.html
http://doc.waterproof.fr/phpedit/debugging_profiling/usage/using_breakpoints
http://www.aptana.com/docs/index.php/Using_the_Breakpoints_View
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp?topic=/com.ibm.wbit.help.debug.doc/topics/tchitbrk.html
http://www.laliluna.de/debugging-jsp-java-tutorial.html
Some of them suspends execution of a thread the n-th time it is hit, but never
again, until it is re-enabled or the hit count is changed or disabled (IBM Web
Sphere, BTW: this is also the behavior of JDI API) and some of them pauses
execution when the hit count is higher than the value in the Skip Hits field.
MSVC has the most rich functionality (as you've mentioned):
http://www.cs.uvm.edu/~upe/resources/debugging/visualStudioCDebug/

All three cases have their uses, so I've decided to include them all. IMHO users
use breakpoint counts mostly for tracking application state. E.g. you need to
stop in 5th iteration of some cycle and procceed from there, or watch a value of
some variable each 100th iteration, etc. Conditions can not be used in all cases
and then the hit count is useful.

In Java debugger we can not show the current hit count. This information is not
available from JDI. Thus your use-case with infinite hit count would not work in
JPDA, because it will not tell you the current hit count upon an error. Counting
it manually in debugger would lead to performance degradation. But C/C++
debugger can provide the current hit count number if it knows it, of course.

Created attachment 42425 [details]
Hit counts filter moved to org.netbeans.api.debugger.Breakpoint

So I've moved the hit count filter into org.netbeans.api.debugger.Breakpoint.

Thanks for the review, I'll commit the change later today...

The API change is integrated in trunk:

/cvs/debuggerjpda/api/apichanges.xml,v  <--  apichanges.xml
new revision: 1.23; previous revision: 1.22

/cvs/debuggerjpda/api/manifest.mf,v  <--  manifest.mf
new revision: 1.24; previous revision: 1.23

/cvs/debuggerjpda/api/src/org/netbeans/api/debugger/jpda/ExceptionBreakpoint.java,v
 <--  ExceptionBreakpoint.java
new revision: 1.5; previous revision: 1.4

/cvs/debuggerjpda/api/src/org/netbeans/api/debugger/jpda/FieldBreakpoint.java,v
 <--  FieldBreakpoint.java
new revision: 1.6; previous revision: 1.5

/cvs/debuggerjpda/api/src/org/netbeans/api/debugger/jpda/LineBreakpoint.java,v 
<--  LineBreakpoint.java
new revision: 1.20; previous revision: 1.19

/cvs/debuggerjpda/api/src/org/netbeans/api/debugger/jpda/MethodBreakpoint.java,v
 <--  MethodBreakpoint.java
new revision: 1.10; previous revision: 1.9

/shared/data/ccvs/repository/debuggercore/api/apichanges.xml,v  <--  apichanges.xml
new revision: 1.10; previous revision: 1.9

/shared/data/ccvs/repository/debuggercore/api/manifest.mf,v  <--  manifest.mf
new revision: 1.16; previous revision: 1.15

/shared/data/ccvs/repository/debuggercore/api/src/org/netbeans/api/debugger/Breakpoint.java,v
 <--  Breakpoint.java
new revision: 1.8; previous revision: 1.7

Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.