> Chitale, Sandip V writes:
> > I agree with you.
> >
> > In terms of features in debugger I would like to see -
> >
> > 1. fast update to different views
> > 2. better variables view (I would like to suggest Java
> based GUI for > this i.e. a treetable)
>
> This is planned.
>
> > 3. storing and managing breakpoints
>
> Ditto.
>
> > 4. breakpoint grouping
>
> Not sure what this is.
For example Karmira's BugSeeker has this feature. I use it this way:
1. I group all my source based breakpoints in one group
2. I group all my exception based breakpoints in another
3. I group all JDK source based breakpoints in third group
4. I group all JDK exception based breakpoints in fourth group
(At one point in time I filled this group with all the
exceptions in
JDK - I simply disable the group most of the time).
5. .... similar groups for other libraries....etc.
I can operate on the group as whole:
1. Delete
2. Enable
3. Disable
Then depending on what kind of debugging I am doing I enable or disable
the groups.
There is some color coding of breakpoints markers based on the group
membership also.
Obviously this is one way of achieving this functionality. There may be
others....
>
> > 4. Different kinds of breakpoints
> >
> > i. conditional breakpoints
>
> This is really hard. It entails creating a Java expression
> parser to parse conditions. JDEbug has an extremely primitive
> parser. I started work on a JavaCC-based parser several years
> ago. It's source code is in the JDEE distribution.
>
> > ii. actions when the breakpoints are hit
>
> Specified how?
Using customization:
1. Stop at breakpoint and/or
2. Print value of a java expression (assuming it is evaluatable)
and/or
3. Stop only every third time (I guess this falls under
conditional
>
> > iii. method entry breakpoint (JPDA allows this)
> > iv. method exit breakpoint
I would like to be able to set these from ECB or speedbar also.
> >
> > a. normal exit
> > b. abnormal exit (exception)
> > c. ability to see return value on the stack (even if it
> > was not
> > stored in some local variable). I am not sure if JDPA
> > allows this.
>
> I'll look into this. If it's supported by the JPDA, it should
> be easy to provide.
>
> > v. Class loading breakpoint
> >
>
> Ditto.
I also missed the following in earlier email.
1. Field access breakpoint
2. Field read breakpoint
3. Field write breakpoint
Breakpoint filters :
1. Thread based
2. Package name regexp based e.g. ignore all NPEs in or.apache.*
etc.
>
> - Paul
>
