|Who debugs the debuggers, part II
||[Oct. 15th, 2005|08:37 pm]
...See also Part I...
The JDB approach is kind of painful. Perhaps, another already
existing debugger can be used to try my approach? So far, I am
intimidated by Eclipse (or NetBeans), and want something easier. The reason
is that at this point my idea of integrating with a debugger is modifying
it to supply my own implementation of a
thus, I need the project whose code is easier to beat into an Eclipse project
As far as more flexible integration with any debugger (for when
this project is "mature") that would not require modifying source
of the said debuggers, I am considering the following. Since
every good debugger has a feature to "attach" to an executing
JVM, I will implement a Java-based "tunnel" for
Looks like GNU Classpath
has done all of the annoying work of implementing the spec.
After examining several alternatives, I have decided, for now, to
first use modified Trace, and,
when that runs out of steam, the Javadt.
I noticed have previously reinvented the wheel when I read
about JPDA but did not notice the existence of
Trace! In an effort
to track down a culprit in an execution of an application, I've replaced
the JVM called with
FoljersCristals -- my homegrown version
Trace. Do I feel silly now...