I recently took over maintenance/development of jdibug, and I am wondering
about what level of integration with JDEE makes sense.
Currently, there is very minimal support: it can be used without JDEE at
all, and the only automatic integration is to use jde-sourcepath if it is
defined and the user requests it.
I know that JDEE has an debugger class, and I could presumably implement a
subclass of this representing JDIbug. However, it's not clear to me what
the benefits of doing so would be. From using JDEbug and the jdb interface,
it appears that many (all?) of the common user commands need a separate
implementation, so I'm not certain what the purpose of the debugger class
is. (I'm not doubting that it has a useful purpose; I just haven't looked
at that part of the code closely enough to know what the value is.)
I have written some integration code for automated testing, and I see a few
potential where more integration would be valuable.
breakpoints: jdibug currently only supports "this file, this line"
breakpoints, which means that if you add code before the breakpoint, you can
end up with a break point on an empty line. jdee uses markers, which avoids
that problem. Could I automatically get marker-based breakpoint support, or
would I need to implement that in jdibug?
advanced breakpoints: I recall a buffer were you could define breakpoints
for things like uncaught exceptions and class loading. Is there still code
to define break points like this (or was it part of JDEbug)? Obviously, I
would need to write code to support those types of breakpoints in JDIbug,
but if there is already code to specify them, that is less work.
jde-run buffer: I have a testing function that calls jde-run and then waits
for output to appear in the buffer indicating the process is ready for the
debugger to connect. (The debugger is the client, the JVM is the server.)
At the moment, there is code the is copy-and-pasted from jde-run to
determine what buffer to check; it would be helpful if jde-run returned the
buffer (or at least provided a function to determine what the buffer is).
If I decide to move this from test code to production code, I should be able
to provide a patch with the functionality.
jde-debugger-running-p: this is currently unaware of jdibug, so the project
file is reloaded if I got to source in a different file. I could fix this
in jdibug with defadvice, but it is probably one of the additional benefits
of implementing a JDEE debugger class. Is that so?
Does anyone have thoughts about how much I would gain by writing JDEE
integration code? There are certainly other features in JDIbug that could
be expanded/added if there isn't much value in the integration.