```
public interface IDebugProtocolClient
```
Declaration of client notifications for the Debug Adapter Protocol

Field Summary

Fields
Modifier and Type Field Description

static java.lang.String SCHEMA_VERSION
Version of Debug Protocol

Method Summary

All Methods Instance Methods Default Methods
Modifier and Type	Method	Description
`default void`	`breakpoint(BreakpointEventArguments args)`	The event indicates that some information about a breakpoint has changed.
`default void`	`capabilities(CapabilitiesEventArguments args)`	The event indicates that one or more capabilities have changed.
`default void`	`continued(ContinuedEventArguments args)`	The event indicates that the execution of the debuggee has continued.
`default void`	`exited(ExitedEventArguments args)`	The event indicates that the debuggee has exited and returns its exit code.
`default void`	`initialized()`	This event indicates that the debug adapter is ready to accept configuration requests (e.g.
`default void`	`invalidated(InvalidatedEventArguments args)`	This event signals that some state in the debug adapter has changed and requires that the client needs to re-render the data snapshot previously requested.
`default void`	`loadedSource(LoadedSourceEventArguments args)`	The event indicates that some source has been added, changed, or removed from the set of all loaded sources.
`default void`	`memory(MemoryEventArguments args)`	This event indicates that some memory range has been updated.
`default void`	`module(ModuleEventArguments args)`	The event indicates that some information about a module has changed.
`default void`	`output(OutputEventArguments args)`	The event indicates that the target has produced some output.
`default void`	`process(ProcessEventArguments args)`	The event indicates that the debugger has begun debugging a new process.
`default void`	`progressEnd(ProgressEndEventArguments args)`	The event signals the end of the progress reporting with an optional final message.
`default void`	`progressStart(ProgressStartEventArguments args)`	The event signals that a long running operation is about to start and provides additional information for the client to set up a corresponding progress and cancellation UI.
`default void`	`progressUpdate(ProgressUpdateEventArguments args)`	The event signals that the progress reporting needs to be updated with a new message and/or percentage.
`default java.util.concurrent.CompletableFuture<RunInTerminalResponse>`	`runInTerminal(RunInTerminalRequestArguments args)`	This request is sent from the debug adapter to the client to run a command in a terminal.
`default java.util.concurrent.CompletableFuture<java.lang.Void>`	`startDebugging(StartDebuggingRequestArguments args)`	This request is sent from the debug adapter to the client to start a new debug session of the same type as the caller.
`default void`	`stopped(StoppedEventArguments args)`	The event indicates that the execution of the debuggee has stopped due to some condition.
`default void`	`terminated(TerminatedEventArguments args)`	The event indicates that debugging of the debuggee has terminated.
`default void`	`thread(ThreadEventArguments args)`	The event indicates that a thread has started or exited.

- Field Detail
  - SCHEMA_VERSION
```
static final java.lang.String SCHEMA_VERSION
```
    Version of Debug Protocol
    
    See Also:
    
    Constant Field Values
- Method Detail
  - initialized
```
default void initialized()
```
    This event indicates that the debug adapter is ready to accept configuration requests (e.g. `setBreakpoints`, `setExceptionBreakpoints`).
    A debug adapter is expected to send this event when it is ready to accept configuration requests (but not before the 'initialize' request has finished).
    The sequence of events/requests is as follows:
    
    adapters sends 'initialized' event (after the 'initialize' request has returned)
    
    client sends zero or more 'setBreakpoints' requests
    
    client sends one 'setFunctionBreakpoints' request (if corresponding capability Capabilities.getSupportsFunctionBreakpoints() is true)
    
    client sends a 'setExceptionBreakpoints' request if one or more 'exceptionBreakpointFilters' have been defined (or if Capabilities.getSupportsConfigurationDoneRequest() is not true)
    
    client sends other future configuration requests
    
    client sends one 'configurationDone' request to indicate the end of the configuration.
  - stopped
```
default void stopped(StoppedEventArguments args)
```
    The event indicates that the execution of the debuggee has stopped due to some condition.
    This can be caused by a breakpoint previously set, a stepping request has completed, by executing a debugger statement etc.
  - continued
```
default void continued(ContinuedEventArguments args)
```
    The event indicates that the execution of the debuggee has continued.
    Please note: a debug adapter is not expected to send this event in response to a request that implies that execution continues, e.g. 'launch' or 'continue'.
    It is only necessary to send a 'continued' event if there was no previous request that implied this.
  - exited
```
default void exited(ExitedEventArguments args)
```
    The event indicates that the debuggee has exited and returns its exit code.
  - terminated
```
default void terminated(TerminatedEventArguments args)
```
    The event indicates that debugging of the debuggee has terminated. This does **not** mean that the debuggee itself has exited.
  - thread
```
default void thread(ThreadEventArguments args)
```
    The event indicates that a thread has started or exited.
  - output
```
default void output(OutputEventArguments args)
```
    The event indicates that the target has produced some output.
  - breakpoint
```
default void breakpoint(BreakpointEventArguments args)
```
    The event indicates that some information about a breakpoint has changed.
  - module
```
default void module(ModuleEventArguments args)
```
    The event indicates that some information about a module has changed.
  - loadedSource
```
default void loadedSource(LoadedSourceEventArguments args)
```
    The event indicates that some source has been added, changed, or removed from the set of all loaded sources.
  - process
```
default void process(ProcessEventArguments args)
```
    The event indicates that the debugger has begun debugging a new process. Either one that it has launched, or one that it has attached to.
  - capabilities
```
default void capabilities(CapabilitiesEventArguments args)
```
    The event indicates that one or more capabilities have changed.
    Since the capabilities are dependent on the client and its UI, it might not be possible to change that at random times (or too late).
    Consequently this event has a hint characteristic: a client can only be expected to make a 'best effort' in honoring individual capabilities but there are no guarantees.
    Only changed capabilities need to be included, all other capabilities keep their values.
  - progressStart
```
default void progressStart(ProgressStartEventArguments args)
```
    The event signals that a long running operation is about to start and provides additional information for the client to set up a corresponding progress and cancellation UI.
    The client is free to delay the showing of the UI in order to reduce flicker.
    This event should only be sent if the corresponding capability InitializeRequestArguments.getSupportsProgressReporting() is true.
  - progressUpdate
```
default void progressUpdate(ProgressUpdateEventArguments args)
```
    The event signals that the progress reporting needs to be updated with a new message and/or percentage.
    The client does not have to update the UI immediately, but the clients needs to keep track of the message and/or percentage values.
    This event should only be sent if the corresponding capability InitializeRequestArguments.getSupportsProgressReporting() is true.
  - progressEnd
```
default void progressEnd(ProgressEndEventArguments args)
```
    The event signals the end of the progress reporting with an optional final message.
    This event should only be sent if the corresponding capability InitializeRequestArguments.getSupportsProgressReporting() is true.
  - invalidated
```
default void invalidated(InvalidatedEventArguments args)
```
    This event signals that some state in the debug adapter has changed and requires that the client needs to re-render the data snapshot previously requested.
    Debug adapters do not have to emit this event for runtime changes like stopped or thread events because in that case the client refetches the new state anyway. But the event can be used for example to refresh the UI after rendering formatting has changed in the debug adapter.
    This event should only be sent if the corresponding capability InitializeRequestArguments.getSupportsInvalidatedEvent() is true.
  - memory
```
default void memory(MemoryEventArguments args)
```
    This event indicates that some memory range has been updated. It should only be sent if the corresponding capability InitializeRequestArguments.getSupportsMemoryEvent() is true.
    Clients typically react to the event by re-issuing a `readMemory` request if they show the memory identified by the `memoryReference` and if the updated memory range overlaps the displayed range. Clients should not make assumptions how individual memory references relate to each other, so they should not assume that they are part of a single continuous address range and might overlap.
    Debug adapters can use this event to indicate that the contents of a memory range has changed due to some other request like `setVariable` or `setExpression`. Debug adapters are not expected to emit this event for each and every memory change of a running program, because that information is typically not available from debuggers and it would flood clients with too many events.
    Since 1.49
  - runInTerminal
```
default java.util.concurrent.CompletableFuture<RunInTerminalResponse> runInTerminal(RunInTerminalRequestArguments args)
```
    This request is sent from the debug adapter to the client to run a command in a terminal.
    This is typically used to launch the debuggee in a terminal provided by the client.
    This request should only be called if the corresponding client capability InitializeRequestArguments.getSupportsRunInTerminalRequest() is true.
    Client implementations of runInTerminal are free to run the command however they choose including issuing the command to a command line interpreter (aka 'shell'). Argument strings passed to the runInTerminal request must arrive verbatim in the command to be run. As a consequence, clients which use a shell are responsible for escaping any special shell characters in the argument strings to prevent them from being interpreted (and modified) by the shell\nSome users may wish to take advantage of shell processing in the argument strings. For clients which implement runInTerminal using an intermediary shell, the 'argsCanBeInterpretedByShell' property can be set to true. In this case the client is requested not to escape any special shell characters in the argument strings.
  - startDebugging
```
default java.util.concurrent.CompletableFuture<java.lang.Void> startDebugging(StartDebuggingRequestArguments args)
```
    This request is sent from the debug adapter to the client to start a new debug session of the same type as the caller.
    This request should only be sent if the corresponding client capability InitializeRequestArguments.getSupportsStartDebuggingRequest() is true.
    A client implementation of `startDebugging` should start a new debug session (of the same type as the caller) in the same way that the caller's session was started. If the client supports hierarchical debug sessions, the newly created session can be treated as a child of the caller session.
    Since 1.59

Interface IDebugProtocolClient

Field Summary

Method Summary

Field Detail

SCHEMA_VERSION

Method Detail

initialized

stopped

continued

exited

terminated

thread

output

breakpoint

module

loadedSource

process

capabilities

progressStart

progressUpdate

progressEnd

invalidated

memory

runInTerminal

startDebugging