The following list defines the events generated for each debug
The getSource() method of a debug event
returns the element associated with the event.
Creation events are guaranteed to occur in a top
down order - that is, parents are created before children.
Termination events are guaranteed to occur in a bottom up order -
that is, children before parents. However, termination events are not guaranteed
for all elements that are created. That is, terminate events can be coalesced - a
terminate event for a parent signals that all children have been terminated.
A debug model may define model specific events by specifying a debug event
kind of MODEL_SPECIFIC. A model specific event is identified by the
event source (i.e. by the debug model that generated the event). The detail of
a model specific event is client defined. Note that model specific events are
not understood by the debug platform, and are thus ignored.
The generic CHANGE event can be fired at any time by any element.
Generally, a client of a debug model, such as as a UI, can get sufficient
information to update by listening/responding to the other event kinds. However,
if a debug model needs to inform clients of a change that is not specified
by create/terminate/suspend/resume, the CHANGE event may be used.
For example, generally, the only way a thread or any of its children can change
state between a suspend and resume operation, is if the thread or owning debug
target is terminated. However, if a debug model supports some other operation
that would allow a debug element to change state while suspended, the debug model
would fire a change event for that element. The valid detail codes for a
change event are:
Clients may instantiate this class. Clients are not intended to subclass this class.