Java Platform Debugger Architecture - FAQs

Please submit a bug report. Be sure to include:

• Sample code that reproduces the problem.
• The text of the run, including the error text.
• Your platform.
• Which SDK (including version) you are using.
• Which version of JPDA you are using.

JPDA is included in the JDK code drops on jdk.java.net In addition the source code for the example programs jdb and trace are included in file demo/jpda/examples.jar in the JDK installation directory.

At this time there are no conformance tests for JPDA.

Yes. Search the internet for 'java ide' and 'java debugger' using your favorite search engine.

Our mission is to create the infrastructure by which quality development tools can be created - not to create the best tools. A simple command line debugger (JDB) is included with JPDA, but most users will find that they are much more productive using a JPDA based IDE such as NetBeans.

Theoretically JPDA could have only one interface, the Java Debug Wire Protocol (JDWP). This would allow cross-platform remote debugging. Java virtual machines would directly use the debuggee side of JDWP and debugger applications would use the debugger side of JDWP. In fact, some Java virtual machines do directly use the debuggee side of JDWP. And some debugger applications do directly use the debugger side of JDWP. Writing directly to JDWP however is painstaking work, information sent across the wire must be read and written precisely. The Java Debug Interface (JDI) is provided to make interfacing to JDWP easier, much easier. Not only does JDI format data to be sent across the wire and parse incoming data, but it provides queuing, caching, connection initiation and many other services. And all this functionality is available from an easy to use (OK, all things are relative) Java programming language interface. In an analogous way, JVM TI insulates Java virtual machine implementors from the intricacies of the debuggee side of JDWP.

If you are writing a debugger (or debugger like tool), the easy answer is, use JDI. You might want to use JDWP if your front-end tool is not written in the Java programming language. You might want to use JVM TI if your tool has very specialized functionality, not available in JDWP/JDI, that can only be performed in the debuggee process and you have a lot of time on your hands.

If you are writing a Java virtual machine the easy answer is, implement JVM TI.

For more information see Why are there three different interface layers in JPDA? and the architecture documentation.

Any Java programming language code run for the purpose of analyzing the behavior of a program (in the same Java virtual machine) interferes with the behavior being analyzed. Some of this interference is subtle, for example: the order that classes are loaded; and the scheduling of threads. More severe however, is competition for resources, for example, if the program being analyzed is holding a lock needed by the analyzing code, deadlock can occur. Finally, many operations can only be reliably performed in a suspended virtual machine; if the virtual machine is suspended the analysis code can not run. At the core of the reliability problems of the old sun.tools.debug interface is that part of its implementation ran as Java programming language code in the debuggee virtual machine. For this reason, the JPDA back-end implementation goes to great pains to avoid the execution of any code in the debuggee virtual machine.

Yes, however this is a case where you would probably need to use JVM TI (see Which interface layer should I use?). We know of one product, not released but working quite well, that uses a combination of JVM TI and native debugging functionality to provide mixed mode debugging.

No.

Yes, JDI allows you to have multiple VirtualMachine objects, each connected to a separate Java virtual machine.

The documentation for com.sun.jdi.VirtualMachine.dispose() describes what happens at detach. If a Java virtual machine is detached properly (with " dispose()"), a debugger can be re-attached.

This is a deprecated option which is accepted and ignored. It need not be specified.

Expression evaluation is currently not included in JPDA. However, there is code in the supplied examples ( in demo/jpda/examples.jar) which implements expression evaluation on top of JDI - see the " expr" package. The JDB application (" tty" package) provides usage examples.

Use com.sun.jdi.ObjectReference.getValue(Field).

The Value can of course come from a previous getValue(). However, you are probably interested in manufactured values like numbers and Strings - use the mirrorOf methods in com.sun.jdi.VirtualMachine, such as VirtualMachine.mirrorOf(boolean).

Variable and line number information is stored in the LocalVariableTable and LineNumberTable attributes of class files. These attributes are optional and compilers generally have flags that control which are generated. For example, by default Sun's javac produces line number but not variable information; the " -g" flag specifies that all debugging information should be generated.