2026.2: BaseInjectedFileChangesHandler internal now, but still API?

[jansorg (Joachim Ansorg)]

The recent 2026.2 eap made BaseInjectedFileChangesHandler.

But that class still has an open class CommonInjectedFileChangesHandler extending it. As far as I understand plugins are allowed to implement InjectedFileChangesHandler and the Base... class and especially CommonInjectedFileChangesHandler seem to be made to be extended.

My plugin extends from CommonInjectedFileChangesHandler to basically provide IndentAwareInjectedFileChangesHandler with additional handling of escaping.

If this was an intentional change, please advise how to handle this.

Thanks!

This is similar to

• DocumentUpdatingActionOnSave was made internal, but is public API
• 2026.2 eap7: "SmartElementDescriptor" was made internal, but is superclass of public API - #3 by nik
• 2026.2: Was PathMacroManager.getInstance intentionally made "@Internal"? - #3 by lucinda

[nik (Nikolay Chashnikov)]

I’ll restore visibility of `BaseInjectedFileChangesHandler` (IJPL-248131), thank you for reporting!