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

**URL:** <https://platform.jetbrains.com/t/2026-3-eap-fileeditoropenrequest-moved-packages-supported-way-to-retain-compatibility-across-263-builds/5253>\
**Category:** IntelliJ Platform\
**Created:** [October 15, 2026, 1:29pm UTC](https://platform.jetbrains.com/t/2026-3-eap-fileeditoropenrequest-moved-packages-supported-way-to-retain-compatibility-across-263-builds/5253 "2026-10-15T13:29:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![chbndrhnns](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/chbndrhnns/32/179_2.png) [@chbndrhnns](https://platform.jetbrains.com/u/chbndrhnns)\
**Post date:** [October 15, 2026, 1:29pm UTC](https://platform.jetbrains.com/t/2026-3-eap-fileeditoropenrequest-moved-packages-supported-way-to-retain-compatibility-across-263-builds/5253/1 "2026-10-15T13:29:22Z")

</div>

# 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:

```plaintext
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:

```kotlin
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](https://plugins.jetbrains.com/docs/intellij/api-changes-list-2026.html), but couldn’t find this package move or the replacement of the synchronous request-based overload.

What is the recommended approach?

Thanks.

---

<div class="post-metadata">

**Author:** ![yuriy.artamonov](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/yuriy.artamonov/32/48_2.png) [@yuriy.artamonov](https://platform.jetbrains.com/u/yuriy.artamonov)\
**Post date:** [October 15, 2026, 2:30pm UTC](https://platform.jetbrains.com/t/2026-3-eap-fileeditoropenrequest-moved-packages-supported-way-to-retain-compatibility-across-263-builds/5253/2 "2026-10-15T14:30:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![yuriy.artamonov](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/yuriy.artamonov/32/48_2.png) [@yuriy.artamonov](https://platform.jetbrains.com/u/yuriy.artamonov)\
**Post date:** [October 15, 2026, 2:33pm UTC](https://platform.jetbrains.com/t/2026-3-eap-fileeditoropenrequest-moved-packages-supported-way-to-retain-compatibility-across-263-builds/5253/3 "2026-10-15T14:33:25Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![chbndrhnns](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/chbndrhnns/32/179_2.png) [@chbndrhnns](https://platform.jetbrains.com/u/chbndrhnns)\
**Post date:** [October 15, 2026, 2:45pm UTC](https://platform.jetbrains.com/t/2026-3-eap-fileeditoropenrequest-moved-packages-supported-way-to-retain-compatibility-across-263-builds/5253/4 "2026-10-15T14:45:29Z")

</div>

> [@chbndrhnns](#):
>
> 263.6800.43

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