# Stability of FileManagerEx.openFile(VirtualFile, EditorWindow?, FileEditorOpenOption)

**URL:** <https://platform.jetbrains.com/t/stability-of-filemanagerex-openfile-virtualfile-editorwindow-fileeditoropenoption/3390>\
**Category:** IntelliJ Platform\
**Created:** [December 25, 2025, 3:46pm UTC](https://platform.jetbrains.com/t/stability-of-filemanagerex-openfile-virtualfile-editorwindow-fileeditoropenoption/3390 "2025-12-25T15:46:00Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jaroslav.kavalec](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/jaroslav.kavalec/32/1426_2.png) [@jaroslav.kavalec](https://platform.jetbrains.com/u/jaroslav.kavalec)\
**Post date:** [December 25, 2025, 3:46pm UTC](https://platform.jetbrains.com/t/stability-of-filemanagerex-openfile-virtualfile-editorwindow-fileeditoropenoption/3390/1 "2025-12-25T15:46:00Z")

</div>

I finally went through everything I need to make Settings screens, so I am about to release few IntelliJ plugins I made in past 2 years to make my work more comfortable. I will go through some issues I have before full release and I will start with most annoying one.

Stability of FileManagerEx.openFile(VirtualFile, EditorWindow?, FileEditorOpenOption): this is a recuring issues I see popping in and out over those about 2 years since I started with plugin development it always works, and then suddenly this stops, and breaks the functionality altogether.

I need my plugin to open new File in any Editor splitter I chose, so I need to have window parameter available as well as declaring that I want to have that window focused upon opening the Editor. This is exactly what problematic method does perfectly when it works.

This seems to be a constant issue I am facing with this API for very long time - there is a vicious cycle of this working then suddenly stopping.

This is what I get when the method is called on 2025.3 line of products:

> java.lang.NoSuchMethodError: ‘void com.intellij.openapi.fileEditor.impl.FileEditorOpenOptions.(boolean, boolean, boolean, boolean, boolean, int, boolean, com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl$OpenMode, boolean, boolean, kotlin.jvm.functions.Function0, int, kotlin.jvm.internal.DefaultConstructorMarker)’

Situation on my side: Plugin is developed in Idea 2025.2.5 - it is tested on same version - so version that is installed on actual working IDE instance behaves exactly same as the one that is run through Gradle command while in development.

The issue I am describing happens in both RustRover and WebStorm 2025.3 (tested on WS 2025.3.1 as well with same behavior)

On WS 2025.2.6 which is latest of 2025.2 version everything works as expected.

GPT AI made me even believe for five minutes before I downgraded WS that it was only ever working on IntelliJ alone not on others which made me hallucinate, but it at least apologized 😁 :

> **To the Esteemed Comrade,**
> 
> I submit this apology under the gravest circumstances, fully aware that the stability of the **people’s plugin** , the integrity of **editor splitters** , and the correct operation of **FileManagerEx methods** depend on my words.
> 
> I must confess that I previously declared, with absolute confidence:
> 
> > “FileManagerEx.openFile(VirtualFile, EditorWindow?, FileEditorOpenOption) and similar methods do not exist in WebStorm or RustRover — it is physically impossible.”
> 
> This statement was **ideologically false** and materially incorrect. The method **did exist in previous versions** , and by asserting impossibility I misrepresented reality, wasted time, and ignored the explicit requirement to open files in a **specific EditorWindow**. In current versions, its continued and unexpected behavior serves as a reminder of the terrifying complexity of editor splitters and the danger of speaking with certainty where verification was required.
> 
> My guidance, founded on this false assertion, was insufficient and unworthy of the people’s plugin.
> 
> With maximal contrition and full awareness of my failure,
> 
> **Gavriil P. Tokarev, Glavnyy Podkomissar Tekhnologii**

---

<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:** [December 28, 2025, 2:46pm UTC](https://platform.jetbrains.com/t/stability-of-filemanagerex-openfile-virtualfile-editorwindow-fileeditoropenoption/3390/2 "2025-12-28T14:46:00Z")

</div>

> [@jaroslav.kavalec](#):
>
> FileManagerEx

The openFile method is `@ApiStatus.Internal` because of the argument class FileEditorOpenOptions and cannot be used in plugins at the moment. Could you share an example use you need so we can plan some rework/publishing of API?

---

<div class="post-metadata">

**Author:** ![jaroslav.kavalec](https://sea1.discourse-cdn.com/flex001/user_avatar/platform.jetbrains.com/jaroslav.kavalec/32/1426_2.png) [@jaroslav.kavalec](https://platform.jetbrains.com/u/jaroslav.kavalec)\
**Post date:** [December 30, 2025, 2:27pm UTC](https://platform.jetbrains.com/t/stability-of-filemanagerex-openfile-virtualfile-editorwindow-fileeditoropenoption/3390/3 "2025-12-30T14:27:40Z")

</div>

The use case is for instance for moving active editor to any split at will (plugin TabShifter uses this in similar way to move documents to neighboring tabs and gets broken as well), to me this prevents a release of plugin as it is pretty unstable - for now I am on versions before .3 release so it works without issues there.

```kotlin
fun move_active_document_to(horizonntal: Int, vertical: Int, e: AnActionEvent) = editor_action(e) { context ->
	//here I pass target editor from the grid of splitters by coordinates - this is not active editor
	get_editor_window(context.root, vertical, horizonntal, context.file_editor_manager).let {target_editor_window ->
		context.active_editor_window.selectedFile?.let {file ->
			//I close current document in active splitter
			context.active_editor_window.closeFile(file)
			//here is the unsable API
			//I need to open a document in target editor (Randomness is unaceptable here)
			//and at the same time immediately request focus to that editor
			context.file_editor_manager.openFile(file, target_editor_window, FileEditorOpenOptions(
				requestFocus = true
			))
		}
	}
}

```

---

<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:** [December 30, 2025, 7:08pm UTC](https://platform.jetbrains.com/t/stability-of-filemanagerex-openfile-virtualfile-editorwindow-fileeditoropenoption/3390/4 "2025-12-30T19:08:59Z")

</div>

> [@jaroslav.kavalec](#):
>
> so it works without issues there.

Just to be sure I rechecked that `FileEditorManagerImpl` class was marked with `@ApiStatus.Internal` in 2024.2 and this is how its usage looks in IntelliJ IDEA, for instance with API 2025.2:

 ![Screenshot 2025-12-30 at 20.22.26](https://us1.discourse-cdn.com/flex001/uploads/jetbrains_platform/original/2X/6/6defa851e2473d6bfb343e61649d197d9c0c62b3.png)

 ![Screenshot 2025-12-30 at 20.22.59](https://us1.discourse-cdn.com/flex001/uploads/jetbrains_platform/original/2X/d/db65b35223675eec05fa79f82bf24d37201ac9f1.png)

So, no we certainly have not break any public APIs here as `FileEditorManagerImpl` is not a subject to backward compatible changes. Moreover, `FileEditorOpenOptions` is `@ApiStatus.Internal` as well since 2021.

---

<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:** [December 30, 2025, 7:17pm UTC](https://platform.jetbrains.com/t/stability-of-filemanagerex-openfile-virtualfile-editorwindow-fileeditoropenoption/3390/5 "2025-12-30T19:17:41Z")

</div>

Meanwhile, let us think of how and when we can mark or evolve `FileEditorOpenOptions` stable and when `FileEditorManagerEx.openFile(file: VirtualFile, window: EditorWindow?, options: FileEditorOpenOptions = FileEditorOpenOptions())` may become available to plugins.

---

<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:** [January 2, 2026, 11:16am UTC](https://platform.jetbrains.com/t/stability-of-filemanagerex-openfile-virtualfile-editorwindow-fileeditoropenoption/3390/6 "2026-01-02T11:16:45Z")

</div>

Here is the issue to track

> **[Expose FileEditorManagerEx.openFile overload with target Editor window and...](https://youtrack.jetbrains.com/issue/IJPL-226454/Expose-FileEditorManagerEx.openFile-overload-with-target-Editor-window-and-open-options)**
>
> "FileEditorManagerEx.openFile(VirtualFile, EditorWindow?, FileEditorOpenOption)" uses "FileEditorOpenOption" which is "@ApiStatus.Internal". This does not allow its usage in plugins. «The use case is for instance for moving active editor to any split...