Hi all,
I'm currently implementing the JDE interface to the new debugger being
developed for the JDE by Amit Kumar of Sun Microsytems. An issue has come
up on which I would like your advice. The issue is how many instances of
the debugger should the JDE allow. Theoretically, I could implement the
interface to allow you, the user, to launch as many instances as you want.
There are some problems with this, however. The first is complexity of
implementation. It would require me to assign and track socket numbers for
each debugger instance started. Also, it increase the complexity of the
user interface. Each session would have a minimum of three windows: a
source window, an application standard I/O window, and a debugger output
window. Thus, two sessions would entail six windows, three, nine, etcs.
Moreover, if you elect to browse stacks or an application's object
hierarchy, there would be even more windows. Managing the multiplicity of
windows would be a complex problem for the JDE and the user.
I should mention some other factors. We are planning to build into the
debugger the ability to launch, control, and inspect multiple processes.
The initial release of the debugger would manage only one process but
ultimately we would add support cor launching and interacting with
multiple, concurrent vm/processes. So my inclination at this point is to go
with the following scheme initially. There will be only one debugger
session per Emacs session, just as now there is only one BeanShell session
per Emacs session. There will be only one process per debugger session.
However, the same debugger session will be able to launch and control
debuggee processes sequentially. Thus, when you select JDE->Debug App from
a source file buffer, the JDE will first check whether a debugger session
is running. If not, it will start a session. Next, it will check whether
the debugger is currently connect to an application vm/process. If not, it
will set any breakpoints that you have specified and invoke the main method
of the main class of the project to which the current source buffer
belongs. It will also pass any command line args that you have specified to
the main method. From this point on, you will not be allowed to debug any
other applications until you stop the current application. When you stop
debugging of an application, the JDE leaves the debugger running, thereby
reducing startup time the next time you want to debug an app.
Later on, you will be able to start another application even when a current
app is running. The debugger will assign a process id to each app/process
that you start and the JDE/Debugger interface will use that ID to route
commands and I/O to the appropriate process.
How does this approach strike you?
- Paul
