Some notes

  1. One can argue that a step from one VM into another should not, from debugger’s point of view, be a step within one thread, but a new thread should be open. But this involves too much interfacing with the debugger (thinking about how to tell it that it needs to register a ThreadStartEvent to open a new thread when it didn’t request it, e.g.), so I scrap the idea, but feel it worthy of noting.
  2. %#@#$%@#$%@^@@^%

    java.lang.ClassCastException: org.hrum.dbdb.DelegatingThreadReference cannot be cast to com.sun.tools.jdi.ThreadReferenceImpl

    Did I mention how this pisses me off?

  3. Ok, even though Dbdb needs Java 6, the proof-of-concept is not supporting
    new JDBC driver
    loading
    … Just a note to self…

Oracle and JPDA

I believed that I had to go through the pain
to bridge
DBMS_DEBUG
to JDWP.
I've already started to look into it, using
GNU Classpath's
implementation
. But it turns out that Oracle
already supports
debugging stored procedures with JPDA
.

But all it does is that saves work on Dbdb, not
makes it irrelevant. While adapting another debugger to
JPDA is useful (and I may yet do it for something else),
it is not the primary value of this project. It is in
the unified call stack.

And David Alpern of Oracle claims they already have
something like this, but it's nowhere to be found.
JDeveloper allows debugging stored procedures
but the
the single call stack, which is what I think
is the ultimate value of Dbdb, is not there...