Re: JDEbug vs jdb vs JSwat vs gdb

Paul Kinnucan wrote:
> Hi Michael,

It's Paul --- Paul Michael to differentiate me from my son Paul Matthew. 
  We have way too many Paul's about --- and nice to hear from you again.

Very good message.

> JDEbug was developed in the early days of the JDEE by a summer intern
> hired by Sun Microsystems. The idea was to develop a debugger designed
> specifically to work with Emacs via standard I/O. Emacs would send
> command-line commands to the debugger and JDEbug would reply with elisp
> that Emacs would execute. This would allow the JDEbug backend to control
> Emacs directly. JDEbug would also provide facilities that jdb didn't,
> such as conditional breakpoints. JDEbug would also provide the ability
> to debug multiple processes concurrently. This requirement was
> unfortunate as it greatly complicated the interface and threading of the
> dubugger, without any benefit. AFAIK, nobody has ever used the
> mutliprocess debugging capability. Anyway, as best as I can tell, the
> intern, who had only 8 weeks to work on this project, basically adapted
> the circa-1997 jdb Java code to work with an Emacs interface that I
> created. He also added the ability to handle multiple processes. He
> never got around to more sophisticated capabilities, such as conditional
> breakpoints. The resulting debugger was slow in stepping and somewhat
> unreliable. Somewhat later I and another JDEE contributor added the
> ability to display local variables in a buffer as you stepped through
> the source. This slowed down stepping even further as all the data had
> to be sent across the standard I/O interface at each step. Somebody else
> added a Java window to display local variables, thus avoiding the
> standard I/O bottleneck. The theoretical advantage of JDEbug is that it
> is specifically designed to work with Emacs and its source code is free.
> The disadvantage is that the source code is complex and difficult to
> maintain and few JDEE contributors have had the time or the willingness
> to take on the task of maintaining and extending the code in any
> significant way.

I spent considerable time yesterday debugging both jdb and JDEbug.  jdb 
has a bug introduced by the latest CVS Emacs.  I'm deep into learning 
how the Bean Shell and Emacs interface and should be able to fix my (and 
Daniel's) problem in a few days or so.  JDEbug has a bug that I 
described in another post.  After having dived into the code your 
comments resonated loud and clear.  I was particularly disturbed by how 
slow JDEbug is.

> Meanwhile, over the years both jdb and the JDEE interface to jdb have
> evolved into a fairly reliable and capable debugger for use with the
> JDEE. Emacs jdb is not anywhere as capable as JSWAT or Eclipse but I
> don't think it has to be for those of us who need and want an
> Emacs-based Java development environment. I've come to the conclusion
> that JDEBug is not the answer for JDEE users who need something more.
> Creating and maintaining a fully capable modern debugger is too much of
> a task for me and, as far as I can tell, for other JDEE contributors. I
> think JDEE development resources would be much better spent trying to
> interface the JDEE to JSWAT or some other independently developed and
> maintained Java debugger. Hence, my proposal that we jettison JDEbug.

Agreed.  Consider it done from my perspective.  I'll not work another 
minute on it.

> A possibility is for someone to start afresh with the JDEBug concept,
> i.e., develop a debugger backend based on an existing free debugger with
> a Java interface specifically designed to talk with Emacs via standard
> I/O or sockets.

Music to my ears.  I'll gladly take any and all comments.  FWIW I hate 
using Eclipse/Intellij/JBuilder/etc.  Emacs is just so resonant with the 
way I like to work.  FWIW, I have three adult sons all doing Java 
engineering work.  One swears by Eclipse, another IDEA and the third 
prefers Emacs.  Dinner conversations are a hoot.

I think the right approach with an enhanced jdb is to provide a more 
standard interface.  I think outputting lisp forms is a bad idea.  XML, 
while it may be more painful to deal with in Emacs is a natural for 
Java, especially when used with a binding tool like JAXB (my preference) 
or Castor.   Losing the multiple process debugging, especially at first 
is another no brainer.  I'll use the Emacs wiki to capture design notes.
I suspect that splitting this debugger from JDE is the right thing to 
do.  A JDE release should include a jar containing this new enhanced 
debugging program.  So I think one of the first things to do is document 
the JDE debugging interfaces that an externally provided debugger should 
support.  How would you capture those interfaces?  I understand full 
well that you are heavily time constrained.  So be it.  We are all glad 
to get whatever time you can afford.

Over the long haul I'm likely to set up a SVN repository for any initial 
work on this UI deprived debug tool on one of my servers at pajato.com. 
  And I'm prone to use Maven as the build system.

Enjoy,

-pmr