Background process is a time-consuming computation usually executed on a background thread. The IntelliJ Platform executes background processes widely and provides two main ways to run them by plugins:
Progress API that allows for cancelling tasks and tracking their progress
Application.executeOnPooledThread() methods for running background tasks that don't need progress tracking
Plugins targeting 2024.1+ should use Kotlin coroutines, which is a more performant solution and provides the cancellation mechanism out of the box.
See Execution Contexts for coroutine-based APIs to use in different contexts.
The Progress API allows running processes on BGT with a modal (dialog), non-modal (visible in the status bar), or invisible progress. It also allows for process cancellation and progress tracking (as a fraction of work done or textual).
The key classes are:
ProgressManager â provides methods to execute and manage background processes
ProgressIndicator â an object associated with a running process. It allows cancelling the process and optionally tracking its progress. The current thread's indicator can be retrieved any time via ProgressManager.getProgressIndicator().
There are many ProgressIndicator implementations and the most commonly used are:
EmptyProgressIndicator â invisible (ignores text/fraction-related methods), used only for cancellation tracking. Remembers its creation modality state.
ProgressIndicatorBase â invisible but can be made visible by subclassing. Stores text/fraction and allows retrieving them and possibly show in the UI. Non-modal by default.
ProgressWindow â visible progress, either modal or background. Usually not created directly but instantiated internally inside ProgressManager.run methods.
ProgressWrapper â wraps an existing progress indicator, usually to fork another thread with the same cancellation policy. Use SensitiveProgressWrapper to allow that separate thread's indicator to be canceled independently of the main thread.
Task â encapsulates an operation to perform. See Task's inner subclasses for backgroundable, modal and other base task classes.
Background processes encapsulated within Task can be run with queueing them. Example:
object : Task.Backgroundable(project, "Synchronizing data", true) { override fun run(indicator: ProgressIndicator) { // operation } } .setCancelText("Stop loading") .queue()
new Task.Backgroundable(project, "Synchronizing data", true) { public void run(ProgressIndicator indicator) { // operation } } .setCancelText("Stop loading") .queue();
To run a backgroundable task under a custom progress indicator, for example, EmptyProgressIndicator to hide progress, use:
ProgressManager.getInstance() .runProcessWithProgressAsynchronously( backgroundableTask, EmptyProgressIndicator())
Note that hiding progress from users should be avoided as it may break the UX.
ProgressManager also allows running Runnable and Computable instances not wrapped within Task with several run*() methods. Example:
ProgressManager.getInstance().runProcessWithProgressSynchronously( ThrowableComputable { // operation }, "Synchronizing data", true, project )
ProgressManager.getInstance().runProcessWithProgressSynchronously( () -> { // operation }, "Synchronizing data", true, project );
CancellationThe most important feature of Progress API is the ability to cancel a process if the result of the computation gets irrelevant. Cancellation can be performed either by a user (pressing a cancel button) or from code when the current operation becomes obsolete due to some changes in the project. Examples:
Cancelling the search for symbol usages (cancellation by user):
The user triggers the Find Usages action in a large project.
Results are being calculated and gradually presented to the user.
The user sees the place they were interested in or realizes that they don't need these results anymore.
The user clicks the cancel button in the status bar, and the operation is canceled.
Code completion (cancellation from code):
The user types a letter in the editor.
Computation of results for code completion is started.
User types another letter.
The computation started in 2. is now outdated and is canceled to start computation for the new input.
Being prepared for cancellation requests in plugin code is crucial for saving CPU resources and responsiveness of the IDE.
Requesting CancellationThe process can be marked as canceled by calling ProgressIndicator.cancel(). This method is called by the infrastructure that started the process, for example, when the mentioned cancel button is clicked, or by code responsible for invoking code completion.
The cancel() method marks the process as canceled, and it is up to the running operation to actually cancel itself. See the section below for handling cancellation.
The cancellation is handled in the running process code by calling ProgressIndicator.checkCanceled(), or ProgressManager.checkCanceled(), if no indicator instance is available in the current context.
If the process was marked as canceled, then the call to checkCanceled() throws an instance of a special unchecked ProcessCanceledException (PCE) and the actual cancellation happens. This exception doesn't represent any error and is only used to handle cancellation for convenience. It allows canceling processes deeply in the call stack, without the need to handle cancellation on each level.
PCE is handled by the infrastructure that started the process and must never be logged or swallowed. In case of catching it for some reason, it must be rethrown. Use inspection Plugin DevKit | Code | Cancellation exception handled incorrectly (2024.3) (previously named 'ProcessCanceledException' handled incorrectly (2023.3)).
All code working with PSI or in other kinds of background processes must be prepared for PCE being thrown at any point.
The checkCanceled() should be called by the running operation often enough to guarantee the process's smooth cancellation. PSI internals have a lot of checkCanceled() calls inside. If a process does lengthy non-PSI activity, insert explicit checkCanceled() calls so that it happens frequently, for example, on each Nth loop iteration. Use inspection Plugin DevKit | Code | Cancellation check in loops (2023.1).
Throwing PCE from checkCanceled() can be disabled in the internal mode for development (for example, while debugging the code) by invoking:
(2023.2+)
(pre-2023.2)
Displaying progress to the user is achieved with:
ProgressIndicator - if available in the current context
ProgressManager - if no indicator instance is available in the current context
To report progress with ProgressIndicator, use the following methods:
setText(String) â sets the progress text displayed above the progress bar
setText2(String) â sets the progress details text displayed under the progress bar
setFraction(double) â sets the progress fraction: a number between 0.0 (nothing) and 1.0 (all) reflecting the ratio of work that has already been done. Only works for determinate indicator. The fraction should provide the user with an estimation of the time left. If this is impossible, consider making the progress indeterminate.
setIndeterminate(boolean) â marks the progress indeterminate (for processes that can't estimate the amount of work to be done) or determinate (for processes that can display the fraction of the work done using setFraction(double)).
ProgressManager allows for reporting progress texts through progress()/progress2() methods, which are counterparts of ProgressIndicator.setText()/setText2(). In addition, it exposes the ProgressIndicator.getProgressIndicator() method for getting an indicator instance associated with the current thread.
ProcessCanceledException and Debugging
Sometimes, a PCE is thrown from checkCanceled() in the code inspected by a plugin developer during a debugging session. If the developer tries to step over a line and this line throws PCE (potentially from a deep call frame), the next place where the debugger stops is a catch/finally block intercepting the exception. This greatly breaks the developer's workflow as the analysis must be started over.
With the Plugin DevKit plugin installed, the debugger will prevent PCE from being thrown during stepping and evaluation with no additional actions needed.
This situation can be avoided by enabling an action available in the internal mode:
Action disabling window deactivation events. This helps avoid PCEs thrown as a result of deactivating the IDE development instance window. For example, when the IDE window is deactivated, it closes the completion popup, which, in turn, cancels the completion process.
Action disabling throwing ProcessCanceledException.
If a topic is not covered in the above sections, let us know via the Was this page helpful? feedback form below or other channels.
Be specific about the topics and reasons for adding them and leave your email in case we need more details. Thanks for your feedback!
05 August 2025
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4