Skip to main content
aboutsummaryrefslogtreecommitdiffstats
blob: 1e584cbbe738a4a0e7bbc0e4158801daa50ed21a (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
<html>
<head>
<title>3.0 Debug Platform Change Notes</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">
<h1>3.0 Debug Platform Change Notes</h1>
<p>This document describes important changes in the 3.0 debug platform, relative 
  to the 2.1 release.</p>
  
<h2>New Features</h2>

<h3> Extensible Launch Modes</h3>
<p>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 - <code>org.eclipse.debug.core.launchModes</code>. 
  The debug platform now defines (contributes) three basic launch modes - run, 
  debug, and profile. Other clients may contribute new launch modes. The launch 
  manager (<code>ILaunchManager</code>) has additional API to retrieve all launch 
  modes, and a human readable label for each launch mode.</p>
<p>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 - 
  <code>org.eclipse.debug.core.launchDelegates</code>. 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).</p>
<p>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. </p>
<p>The debug platform has added an optional element (<code>launchMode</code>), 
  to the definition of a launch tab group extension - <code>(org.eclipse.debug.ui.launchConfigurationTabGroup</code>), 
  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 <code>launchMode</code> element defines a <code>perspective</code> 
  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.</p>
<p>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.</p>
  
<h3>Extensible Debug Events</h3>
<p>The debug platform supports an extensible set of debug events. A debug event 
  kind of <code>MODEL_SPECIFIC</code> has been added in the 3.0 release to indicate 
  an application specific debug event. When a debug event of kind <code>MODEL_SPECIFIC</code> 
  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.</p>
<p>A data field has been added to debug events to allow clients to store application 
  specific data in debug events.</p>
  
<h3>Editor Positioning and Custom Annotations</h3>
<p>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 
  interface <code>IDebugEditorPresentation</code> 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.</p>

<h3>Extensible Watch Expressions</h3>
<p>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.</p>

<h3>Process Factories</h3>
<p>The debug platform provides an extension point (<code>org.eclipse.debug.core.processFactories</code>) 
  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.<code> 
  org.eclipse.debug.core.DebugPlugin</code>) 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 <code>DebugPlugin.ATTR_PROCESS_FACTORY_ID</code>.</p>

<h3>Automatic Array Partitioning</h3>
<p>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 - <code>org.eclipse.core.debug.model.IIndexedValue</code>. 
  If a value implements this interface, the variables view will automatically 
  partition its elements as required, into sub-ranges</p>

<h3>Logical Structure Types</h3>
<p>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 (<code>org.eclipse.debug.core.logicalStructureTypes</code>) allowing 
  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 display.</p>

<h3>Step Filters</h3>
<p>To support step filters on all stepping functions (into, over, return), a new 
  interface has been added to the debug platform - <code>IStepFilters</code> - 
  which can be implemented by debug targets. This interface replaces <code>IFilteredStep</code>, 
  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 
  on <code>DebugUITools</code> 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 <code>IStepFilters</code> for more details.</p>
<p>This change maintains binary compatibility with previous releases. However, 
  targets wishing to leverage the new function must implement the new interface.</p>

<h3>Launch Termination Notification</h3>
<p>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
  <code>ILaunchesListener2</code>.</p>
  

<h3>Launch Delegate Enhancements</h3>
<p>Lanuch delegates can optionally implement the new interface <code>ILaunchConfigurationDelegate2</code>. 
  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.</p>

<h3>Retargettable Actions</h3>
<p>The debug platform now provides retargettable actions for the following actions.</p>
<ul>
  <li>Run to Line</li>
  <li>Toggle Line Breakpoint</li>
  <li>Toggle Method Breakpoint</li>
  <li>Toggle Watchpoint</li>
</ul>
<p>Debug implementations can plug into the retargettable actions by providing 
  appropriate adapters for relevant editors and model objects that perform the 
  actual operations (<code>IRunToLineTarget</code> and <code>IToggleBreakpointsTarget</code>, 
  defined in the <code>org.eclipse.debug.ui.actions</code> 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.</p>
<p>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: <code>RunToLineActionDelegate</code>, <code>ToggleMethodBreakpointActionDelegate</code>, 
  and <code>ToggleWatchpointActionDelegate</code> in the <code>org.eclipse.debug.ui.actions</code> 
  package.</p>
  
<h2>API Changes</h2>

<h3>Debug Action Groups removed</h3>
<p>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.</p>
<p>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++").</p>

<h3>Extensible Launch Modes</h3>
<p>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 <code>ILaunchConfigurationType.getDelegate()</code> 
  is now deprecated. The method <code>getDelegate(String mode)</code> 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 
  <code>run</code> mode.</p>

<h3>Launch Tabs &amp; Tab Groups</h3>
<p>Launch tab groups and launch tabs are no longer notified when a launch completes. 
  The method <code>launched(ILaunch)</code> in the interfaces <code>ILaunchConfigurationTab</code> 
  and <code>ILaunchConfigurationTabGroup</code> 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 
  exists.</p>

<h3>Perspective Switching</h3>
<p>In prior releases, perspective switching was specified on a launch configuration, 
  via the launch configuration attributes <code>ATTR_TARGET_DEBUG_PERSPECTIVE</code> 
  and <code>ATTR_TARGET_RUN_PERSPECTIVE</code>. 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 <code>DebugUITools</code> 
  to set and get the perspective associated with a launch configuration type for 
  a specific launch mode.</p>
<p>An additional, optional, <code>launchMode</code> element has been added to 
  the <code>launchConfigurationTabGroup</code> extension point, allowing a contributed 
  tab group to specify a default perspective for a launch configuration type and 
  mode.</p>
<p>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.</p>

<h3>Generic Console</h3>
<p>With the work for the generic console support <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37263"> 
  (Bug 37263)</a>, 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".<br>
  The generic console is available via the Window>Show View>Basic>Console and 
  is used by the Eclipse debug and Ant integration. </p>

<h3>Console Line Tracker Extension</h3>
<p>A console line tracker (<code>IConsoleLineTracker</code>) can be notified when 
  its associated console is closed (i.e. all of its streams are closed), by implementing 
  the new interface <code>IConsoleLineTrackerExtension</code>. The notification 
  indicates that no more output will be appended to the console.</p>

<h3>Launch Configuration Tab Enhancements</h3>
<p>Two methods have been added to the <code>ILaunchConfigurationTab</code> interface 
  - activated and deactivated. These new life cycle methods are called when a 
  tab is entered and exited respectively. Existing implementations of <code>ILaunchConfigurationTab</code> 
  that subclass the abstract class provided by the debug plug-in (<code>AbstractLaunchConfigurationTab</code>) 
  will maintain binary compatibility, as the methods have been added in the abstract 
  class.</p>
<p>In prior releases, a tab was sent the message <code>initializeFrom</code> when 
  it was activated, and <code>performApply</code> 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. </p>
<p>To avoid breaking the behavior of current tab implementations, the default 
  implementation of <code>activated</code>, provided by the abstract tab, calls 
  <code>initializeFrom</code>. And, the default implementation of <code>deactivated</code> 
  calls <code>performApply</code>. 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 
  nothing.</p>
  
<h3>BreakpointManager Can Be Disabled</h3>
<p>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.</p>
<p>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.</p>
</body>
</html>

Back to the top