Microsoft SDK for Java

Implementing Callback Notification Interfaces

For the Microsoft VM to communicate with a debugger, the debugger registers with the debugger manager and passes in pointers to its notification interfaces. The Java debugger implements two COM interfaces for this callback mechanism:

See the Notification Debugger Interfaces reference for details.

The debugger is notified through its ProcessCreateEvent method that a new Java process has been created. If the debugger decides to, it can register to receive notifications regarding this specific Java process. The IRemoteProcessCallbackEx2 interface is the primary way the Microsoft VM communicates with the debugger about a specific Java process. This callback has a large number of event notification methods that are implemented by the debugger.

Objects underlying the COM objects are obtained by a debugger application from the Microsoft VM. These underlying objects are obtained through an event callback notification or by calling VM-implemented methods. Certain VM-implemented methods will fail once the associated object's lifetime is over. For example, calling the Step method will fail on an IRemoteThread whose associated Java thread has already terminated.

After a debugger registers an interest in a particular Java process (IRemoteProcess), it will receive calls to its ClassLoadEvent method for each class that was loaded before the debugger was attached. After notifications are made for all the currently loaded classes, a LoadCompleteEvent is received. After this notification, any other ClassLoadEvent notifications are sent synchronously for the thread that caused the class to be loaded.

Java process execution is suspended during IRemoteProcessCallbackEx2 method calls. If the debugger returns S_OK from an IRemoteProcessCallbackEx2 method, the Java process remains suspended. Execution of the Java process is resumed when the debugger calls Go. If the debugger returns S_FALSE from an IRemoteProcessCallbackEx2 method, the Java process resumes execution immediately.

IRemoteProcess::FindClass can be used to force a class to be loaded into the Microsoft VM if it is not already loaded. This method has the side effect of causing the debugger to receive ClassLoadEvent method calls. The initializer for the Java class may also run and the debugger will receive events during execution of the initializer. For example, if an exception occurs in the initializer, the debugger will receive an ExceptionEventEx method call.

Thread groups have special meaning for security purposes. Each Java applet is given its own thread group, and the applet can only manipulate threads within that group. These thread groups may be used to differentiate threads among multiple applets.

The debugger is notified when thread groups and individual threads are created and destroyed. Threads are used extensively to get dynamic information when debugging Java code.

The debugger receives notifications on breakpoint and step events. The debugger sets breakpoints and controls execution by calling methods on the execution control interfaces. The execution control interfaces are based on threads.

© 1999 Microsoft Corporation. All rights reserved. Terms of use.