Hi All,
I have some wonderful news to announce. Sun Microsystems has hired a summer
intern, Amit Kumar, to develop a debugger for the JDE. Amit is studying for
a PhD in computer science at the University of Southern California and is
an experienced JDE user. The debugger he will be developing in the next few
months will be based on Sun's new JDI debugger framework. The long-range
goal is to provide JDE users with a more robust and fully featured debugger
and to showcase Sun's new debugger framework. The goal for the internship
period is to get basic functionality implemented and into users hands and
to create a solid foundation for future enhancements. The debugger will be
implemented in Java. The Emacs interface will be implemented in Emacs Lisp.
Both the Java and Lisp code will be GPLed.
Amit and I and some other members of the JDI team have been having some
preliminary discussions on the design of the new debugger. We'd now like to
throw the discussion open to the JDE list so as to get your input on
critical design and implementation issues.
To that end, Amit and I plan to use the JDE list as our primary
communications channel on design issues so that you can eavesdrop and
comment on any issue that concerns you. We also encourage you to raise
issues on the list to which we will respond. Amit and I are sensitive to
the concerns that the list not glut your inboxes. To this end, we will
confine our posts to design issues and plans and not clutter the list with
administrative trivia or discussions of implementation details. In any
event, it is our hope to have a spec finalized within a week and when that
happens the traffic on this subject should taper off.
As a way of starting the discussion, I have summarized some design
decisions that Amit, I, and the JDE team have reached provisionally. We'd
be interested in your feedback on these points.
Regards,
- Paul
Preliminary Design Specifications
=========================
Note: in what follows, phrases of the sort "if time permits" refer only to
the period of Amit's internship. Features not implemented during the
internship period will be tackled afterward by myself, Amit, or anybody
else interested in participating in this endeavor.
At this point, we have reached the following preliminary design decisions:
* The new debugger will be based on a reference JDI-based debugger already
developed by the JDI team but will be modified to interface with the JDE
and will be extended if necessary to support JDE-specific functionality.
* The debugger and the JDE will communicate via a dedicated socket channel.
This will facilitate debugging applications that use standard I/O.
* The JDE will drive the debugging session by issuing commands using a
command language that we will design. Debugger responses will be Lisp
expressions to avoid the need for a specialized parser.
* The debugger user interface will be Emacs commands (implemented as Lisp
functions) which will be bound to menus and keystrokes, e.g., there will be
an Emacs function, jdebug-step-over, which can be invoked in three ways:
by typing M-x jdebug-step-over; by typing F10 (or some other keyboard
accelerator); or by selecting JDEbug->Step Over from the Emacs menubar.
* JDEbug will give the user the option of using either a highlight or an
arrow as the debug cursor.
* Debugger output will be displayed in a dedicated read-only buffer.
* Application standard I/O will be displayed in a dedicated comint buffer.
Note: this means that in a typical debug session, you will have the source
in one buffer, the debug output in another, and there will be a third
buffer for interacting with the application via standard I/O.
* The debugger will support setting breakpoints by line within a source file
or method within a class.
* If time permits, the debugger will support conditional breakpoints, i.e.,
a breakpoint is enabled only if a boolean expression comprising in-scope
variables is true.
* The JDE will provide support for persistant breakpoints, i.e., you can
specify that breakpoints from a previous debugging session be reset
automatically in the current session. The implementation of this feature
will probably involve saving the breakpoints in a project file.
* Watchpoints can be set on object fields, i.e., the debugger halts
execution of
the application when a watched field is modified. The current line is
indicated
in the source buffer.
* A goal is to implement automatic display of in-scope variable values in
the debugger
buffer. In other words, the JDE/debugger figures out which variables are
referenced in the current line and displays them in the debugger buffer
along with
their values.
* Navigating up and down stack frames will be supported. We need guidance
on how this feature should work.
* Support for debugging multithreaded applications is a design goal. We
need input on what features are useful for this purpose.
I plan to pull together a wishlist of features based, in part, on previous
mail to this list on the subject. I hope to have it ready for comment today
or tomorrow.
