This document describes important changes in the 3.0 debug platform, relative to the 2.1 release.
The debug platform supports an extensible set of launch modes. Releases prior
to 3.0 only supported two launch modes - run and debug. The debug platform now
provides an extension point for contributing new launch modes -
The debug platform now defines (contributes) three basic launch modes - run,
debug, and profile. Other clients may contribute new launch modes. The launch
ILaunchManager) has additional API to retrieve all launch
modes, and a human readable label for each launch mode.
The debug platform has a new extension point to support the contribution of
a launch delegate for a specific launch configuration type and launch mode -
org.eclipse.debug.core.launchDelegates. This allows launch configurations
to be extended by third parties, to support new launch modes. For example, a
client could contribute a launch delegate that launches a Java Application in
profile mode (currently, the SDK does not provide a profiler).
For backwards compatibility, the launch delegate supplied by a launch configuration type extension is used for the launch modes specified by the launch configuration type. A launch delegate supplied for a specific mode, is used only for that mode.
The debug platform has added an optional element (
to the definition of a launch tab group extension -
to support the contribution of a set of tabs for a specific launch configuration
type and launch mode. This allows third parties to extend an existing launch
configuration user interface. For example, a client contributing a launch delegate
to profile a Java Application would also contribute a set of tabs to configure
the profiler. The
launchMode element defines a
attribute to specify the default perspective associated with the launch configuration
type and mode. This controls the perspective that is switched to/opened, by
default, when a configuration is launched in the associated mode. For example,
a client contributing a profiler may also contribute a profiling perspective
that should be displayed when an application is profiled.
For backwards compatibility, the tab group contributed for a launch configuration type (specifying no launch mode), is used for all launch modes for which a specific launch tab group is not contributed. Thus, when a mode is not specified by a tab group, the tab group effectively becomes the default tab group.
The debug platform supports an extensible set of debug events. A debug event
MODEL_SPECIFIC has been added in the 3.0 release to indicate
an application specific debug event. When a debug event of kind
is created, the detail code in the event is client defined. The source of the
event (debug element that generated the event) identifies the debug model from
which the event was generated. The debug platform and user interface ignores
model specific debug events.
A data field has been added to debug events to allow clients to store application specific data in debug events.
In release 3.0, a debug model presentation can position and annotate editors
opened by the debugger for stack frames. This is done by implementing the new
IDebugEditorPresentation on the applicable debug model
presentation. When implemented, the model presentation is used as a delegate
to position editors, add annotations, and remove annotations for stack frames.
In release 3.0, the debug platform provides an implementation of watch expressions. Debug models can contribute watch expression delegates if they support watch expressions. When a stack frame is selected, the associated delegate is queried to provide a value for a watch expression in the given (stack frame) context. The debug platform provides persistence, enabling, disabling, entering, and editing of watch expressions.
The debug platform provides an extension point (
for contributing process factories. A process factory can be used to override
default process creation for a launch configuration when the debug plug-in (i.e.
org.eclipse.debug.core.DebugPlugin) is consulted to create a new process.
A launch configuration can reference a process factory to use when creating
a process, via the launch configuration attribute
The debug plug-in now supports automatic array partitioning in the variables,
which partitions large arrays into sub-ranges in the variables view. This is
supported with the introduction of a new interface in the debug model representing
an indexed value -
If a value implements this interface, the variables view will automatically
partition its elements as required, into sub-ranges
Often, it is convenient to navigate complex data structures in terms of a logical
structure, rather than an implementation structure. For example, no matter how
a list is implemented (i.e. linked list, collection of arrays, etc.), it is
often convenient to be able to view the list as an ordered collection. To facilitate
the display of logical structures in the variables view, an extension point
has been added (
debug models to contribute logical structures of its values, where applicable.
Debug models may contribute delegates to translate raw implementation values
into logical values. The variables view will display the logical values, when
the option to display logical structures is turned on. More than one logical
structure can be provided for a single value - the user can choose which structure
To support step filters on all stepping functions (into, over, return), a new
interface has been added to the debug platform -
which can be implemented by debug targets. This interface replaces
which is now deprecated. The debugger provides a global toggle that turns step
filters on/off for all stepping functions. Toggle actions are provided in the
Run menu, Debug View context menu, and Debug View toolbar, which replaces the
'Step with Filters' action in previous releases. As well, an API is provided
DebugUITools to modify step filter enablement. It is up to debug
targets to implement this new interface and to honor the step filter enablement
setting when stepping. See javadoc for
IStepFilters for more details.
This change maintains binary compatibility with previous releases. However, targets wishing to leverage the new function must implement the new interface.
A new interface has been introduced to provide a mechanism for launch listeners
to be notified when a launch terminates. A launch is simply a container of processes
and debug targets. When all of the contained targets and processes terminate,
a terminate notification is now sent to those listeners that implement
Lanuch delegates can optionally implement the new interface
This allows launch delegates to provide a launch object to be used for a launch.
For example, when debugging on a server a delegate could create a new launch
object or may reuse an existing launch object if the server is already running
in debug mode.
The debug platform now provides retargettable actions for the following actions.
Debug implementations can plug into the retargettable actions by providing
appropriate adapters for relevant editors and model objects that perform the
actual operations (
defined in the
org.eclipse.debug.ui.actions package). A retargettable
action works on the active part. First the part is asked for a target adapter.
If the part does not provide an adapter, the selected objects within the part
are consulted for adapters.
As well, action delegates actions are provided by the debug platform such that
debug implementations can contribute appropriate actions to context menus. An
editor actions delegate is provided for the run to line action, and an object
action delegate is provided for toggling method breakpoints and watchpoints.
See the following classes:
ToggleWatchpointActionDelegate in the
The Debug Action Groups extension point (org.eclipse.debug.ui.debugActionGroups) has been removed. In Eclipse 3.0, the workbench introduced support for Activities via the org.eclipse.platform.ui.activities extension point. This support provides everything that Debug Action Groups provided and is also easier to use (it supports patterns instead of specifying all actions exhaustively) and has a programmatic API to support it.
Failing to remove references to the old extension point won't cause any failures. References to the extension point will simply be ignored. Product vendors are encouraged to use the workbench Activities support to associate language-specific debugger actions with language-specific activities (for example, C++ debugging actions might be associated with an activity called "Developing C++").
With the introduction of extensible launch modes, more than one launch delegate
can exist for a launch configuration type. Releases prior to 3.0 only supported
one launch delegate per launch configuration type. The method
is now deprecated. The method
getDelegate(String mode) should be
used in its place to retrieve the launch delegate for a specific launch mode.
The deprecated method has been changed to return the launch delegate for the
Launch tab groups and launch tabs are no longer notified when a launch completes.
launched(ILaunch) in the interfaces
ILaunchConfigurationTabGroup has been deprecated and is no
longer called. Relying on this method for launch function was always problematic,
since tabs only exist when launching is performed from the launch dialog. Also,
with the introduction of background launching, this method can no longer be
called, as the launch dialog is be closed before the resulting launch object
In prior releases, perspective switching was specified on a launch configuration,
via the launch configuration attributes
ATTR_TARGET_RUN_PERSPECTIVE. With the addition of extensible
launch modes in 3.0, this approach no longer scales. Perspective switching is
now specified on launch configuration type basis, per launch mode that a launch
configuration type supports. API has been added to
to set and get the perspective associated with a launch configuration type for
a specific launch mode.
An additional, optional,
launchMode element has been added to
launchConfigurationTabGroup extension point, allowing a contributed
tab group to specify a default perspective for a launch configuration type and
From the Eclipse user interface, users can edit the perspective associated with a launch configuration type by opening the launch configuration dialog, and selecting a launch configuration type node in the tree (rather than an individual configuration). A tab is displayed allowing the user to set a perspective with each supported launch mode.
With the work for the generic console support
(Bug 37263), the view id for the Eclipse (formerly debug) console has changed.
This results in problems at startup such as "Could not restore workbench layout"
with details that "Could not create view: org.eclipse.debug.ui.ConsoleView"
for the particular perspective that contained reference to the old view id.
The equivalent view id is now: "org.eclipse.ui.console.ConsoleView".
The generic console is available via the Window>Show View>Basic>Console and is used by the Eclipse debug and Ant integration.
A console line tracker (
IConsoleLineTracker) can be notified when
its associated console is closed (i.e. all of its streams are closed), by implementing
the new interface
IConsoleLineTrackerExtension. The notification
indicates that no more output will be appended to the console.
Two methods have been added to the
- activated and deactivated. These new life cycle methods are called when a
tab is entered and exited respectively. Existing implementations of
that subclass the abstract class provided by the debug plug-in (
will maintain binary compatibility, as the methods have been added in the abstract
In prior releases, a tab was sent the message
it was activated, and
performApply when it was deactivated. In
this way, the launch configuration tab framework provided inter-tab communication
via a launch configuration (by updating the configuration with current attribute
values when a tab is exited, and updating the newly entered tab). However, since
many tabs do not perform inter-tab communication, this can be inefficient. As
well, there was no way to distinguish between a tab being activated, and a tab
displaying a selected launch configuration for the first time. The newly added
methods allow tabs to distinguish between activation and initialization, and
deactivation and saving current values.
To avoid breaking the behavior of current tab implementations, the default
activated, provided by the abstract tab, calls
initializeFrom. And, the default implementation of
performApply. Tabs wishing to take advantage of the new API
should override these methods as required. Generally, for tabs that do not perform
inter-tab communication, a correct implementation of these methods is to do
IBreakpointManager now defines the methods setEnabled(boolean) and isEnabled(). When the breakpoint manager is disabled, debuggers should ignore all registered breakpoints. The debug platform also provides a new listener mechanism, IBreakpointManagerListener which allows clients to register with the breakpoint manager to be notified when its enablement changes.
The Breakpoints view calls this API from a new toggle action that allows the user to "Skip All Breakpoints." Debuggers which do not honor the breakpoint manager's enablement will thus appear somewhat broken if the user tries to use this feature.