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. Troy
------------------------------------------------------------------------------
_______________________________________________ jdee-devel mailing list jdee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdee-devel
