2026.3 EAP: FileEditorOpenRequest moved packages - supported way to retain compatibility across 263 builds?

IntelliJ Platform
1

2026.3 EAP: FileEditorOpenRequest moved packages — supported way to retain compatibility across 263 builds?

Hi,

I maintain BetterPy, a PyCharm plugin. Its test/production editor-tab feature moves files into designated editor splits while preserving selection, focus, pin state, and caret position.

The plugin is compiled against PyCharm 263.6259.38 and declares compatibility through 263.*. We received this runtime error:

java.lang.NoClassDefFoundError:
  com/intellij/openapi/fileEditor/ex/FileEditorOpenRequest
    at ...IntellijTestProductionEditorTabLayout.openFile(...)
Caused by: java.lang.ClassNotFoundException:
  com.intellij.openapi.fileEditor.ex.FileEditorOpenRequest

The relevant call is:

import com.intellij.openapi.fileEditor.ex.FileEditorOpenMode
import com.intellij.openapi.fileEditor.ex.FileEditorOpenRequest

manager.openFile(
    file,
    FileEditorOpenRequest(
        targetWindow = targetWindow,
        openMode = FileEditorOpenMode.DEFAULT,
        selectAsCurrent = selectAsCurrent,
        reuseOpen = true,
        usePreviewTab = false,
        requestFocus = selectAsCurrent,
        pin = pin,
    ),
)

Comparing the platform binaries for 263.6259.38 and 263.6800.43:

  • In 263.6259.38, FileEditorOpenRequest and FileEditorOpenMode are in com.intellij.openapi.fileEditor.ex, with a synchronous FileEditorManagerEx.openFile(file, request) overload.
  • In 263.6800.43, those classes are in com.intellij.openapi.fileEditor. The earlier synchronous overload is absent; the newer API includes requestOpenFileInWindow(...) returning a CompletableFuture and suspending openFileInWindow(...).
  • Both builds retain the synchronous openFile(file, window, FileEditorOpenOptions) overload, but that method and FileEditorOpenOptions are marked @ApiStatus.Internal.

I understand that the earlier request API was marked experimental. My concern is how to support these 263 EAP builds in one plugin artifact without introducing internal-API dependencies or changing the layout logic to assume an editor is available before an asynchronous open completes.

I checked the 2026 incompatible API changes list, but couldn’t find this package move or the replacement of the synchronous request-based overload.

What is the recommended approach?

Thanks.

2

Hi, unfortunately there is no way, FileEditorOpenRequest is still experimental and we really needed to move it for new async opening APIs. We do not document all experimental and internal API changes as breaking changes.

We usually recommend having branches for stable Major releases of IDE in such cases.

3

When plugins use @Experimental we expect that you perform code migration on breaking changes, you agree to that having those warnings.

Both builds retain the synchronous openFile

Here I must comment that we strongly discourage synchronous navigation everywhere as it is a constant source of UI freezes for users

4

I bumped the minimal build to this version and will use the async API’s. Thanks for the response!