Re: JDEbug vs jdb vs JSwat vs gdb

On Tue, 1 Aug 2006, [email protected] wrote:
> Hi Michael,
> 
> 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.

Just curious (Talking from somebody who tried JDEbug quite a few times,
but hasn't used it in a couple of years).  I use speedbar very sparingly
because of how "slow" I see it.  Everytime I "click", it seems to have
to work fairly hard to explode although it seems faster in later
releases, but I still don't find myself using it (even with the ECB
complete integration with it, I don't use it).  I then remember the
JDEbug interface and it seemed quite similar to how speedbar presented
itself.  My question is where is most of the slowness in the JDEbug?  Is
it from the interface of the standard I/O socket to Emacs lisp engine or
from the recieving of the lisp structures to the display of the
interface to the user?  Is is just the combination of both of those
things because both are heavy?

But also, on this same topic, I love ECB even though it can also seem as
"slow" as the speedbar interface.  That is because I'm okay with waiting
for what the ECB brings me which is "the exact place in the file" as
compared to the speedbar where I have to "click again to see the code"
or the JDEbug where I'm trying to "get to the bug quickly" and not wait
for the interface.  Maybe, as you say, the JDEbug will never meet the
needs really because of an elisp performance limitation?


> 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. 

It seems to me that Emacs has been playing catch-up with the JVM in a
big way.  Once the JVM showed up, IDE's that were written in the JVM and
allowed the user to interact with that JVM started poping up.  Here
comes Emacs in an EVM (Elisp Virtual Machine) and it has no capability
of "reflecting" on objects in a completely different Virtual Machine.
But, you, Paul, conquered that hurdle for all of Emacs.  When you say
the jdb won't start surpassing the other IDEs it seemed to sound like
Emac's capablitity of debugging java processes will never be as good as
a java based one.  The amount of new functionality added to the
java-based IDEs at their core doesn't seem to be at a rapid pace.
Eclipse has the plug-in architecture, but Emacs's plug-in architecture
is fabulous, witness the "Emacs Lisp List" or the hundreds of elisp
projects scattered around the web.  The more the beanshell has an
interface totally supported by elisp, the more the rest of the elisping
Emacs world can interact with the JVM's of the world.  Why should we
think that Emacs isn't even close to what it can/will be in the future.
The rest of the world is stuck in a very non-productive world when
trying to interact with remote hosts, while Emacs is just fabulous at
it.  We even have TRAMP.  I use Gnus.  Who would have thought that
email, newsgroups, webboards, directories, and pretty much anything with
structure could come back looking like a threaded conversation?  Dired?
I can't live without it.  The list goes on and on.  Emacs always keeps
plugging along, making the experience more and more pleasing/productive.


> 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.

I hope you don't completely jettison the code.  Your code is too good to
just give up on.

My gut feeling is that the biggest problem is you didn't branch your
code.  Then, because of that fateful decision, you've committed your
elisp work to the JDEbug _exclusively_.  Therefore, you don't get to see
the fruits of your labors with your users using new features, submitting
bug reports and working with others, ie, you aren't seeing the JDEE
grow. I believe the personal satisfaction of developing the JDEE has
somewhat been taken from you with this single branch.  But, I also fear
that this has manifested itself in your feeling discouraged in the
JDEbug.  I think JDEbug ALWAYS held loads of promise, cause, if you had
been able to solidify how well it works and how fast it works, we JDEE
users would have been completely thrilled, and I mean thrilled with
it!!!  Can I say again, if I could have legitimately debugged weblogic
by attaching to its debugging port with a GUI in Emacs, I would have
been 100% thrilled.  I would not need to use Eclipse anymore.  That is
the single reason I have to leave Emacs and go to eclipse.  And, on top
of that, Eclipse is good enough that I stay there for java development,
because switching between the two environments is too-cumbersome.  Emacs
is much more pleasing editor of the code and I am much more efficient
within Emacs, but eclipse is a button click away from debugging the
latest change...  So, without the JDEbug, my java development
environment is eclipse.  Everything else in my day is Emacs, but I use
Eclipse for too much of my java work.

You also made it a point to make the JDEE very usable by the mouse,
which is important to being able to stand on par with Eclipse as an IDE.
Your commitment to this is something I also hope you never lose.  The
more Emacs can be "driven" by the mouse as well as being "used" by a
keyboardist, the better for the entire community.

Look at your project structure.  Is it too far fetched to see this idea
support all types of projects?  You've made beanshell usable on its own,
heck, you've allowed an elisp engine to even talk to a java engine
through beanshell.  You've integrated ant beautifully.  You've designed
a plug-in interface.  

I guess I'm pleading that you make sure that the JDEbug has a branch of
its own where you and others can go and daudle when you feel like taking
on the task.  That interface is what all of Emacs really needs.  Maybe
you could somehow join the JDEbug with the ECB forces and take it to a
higher level?  Maybe JDEbug really becomes EGUIDebug or something ...

Maybe the GUI is just used to set watch expressions while jdb is for
stepping and examining?

Maybe the GUI just shows the available variables for completion while
one is within the jdb?

Maybe the jdb interface can have small windows into the JDEbug
structures for more performant display of debugging contents?

Is there anyway that the edebug interface could be extended to use
against a java I/O engine and talk to the GUI and the GUI talk to it?  I
could see

     "space" mean "step over"
     "C-space" mean "step into"
     "C-u -1 space" mean "step out"


-- 
Galen Boyer