Many unexpected breaking changes in 2026.1 EAP

IntelliJ Platform
1

I was finally able to build my plugin against 2026.1 EAP 3 now that it’s possible to create a plugin SDK against it from within the IDE, and I found a pretty significant set of unexpected breaking changes.

I’ve been able to get things to build, but that required me to disable several things that have worked just fine against years and years of previous versions, specifically things that don’t seem to have been denoted as deprecated, internal, etc. Here’s a list of specific things that are suddenly gone:

  • projectStructureValidator EP and associated classes

  • projectStructureDetector EP and associated classes

  • com.intellij.openapi.roots.ui.configuration.ProjectStructureConfigurable

  • com.intellij.openapi.roots.ui.configuration.projectRoot.ModuleStructureConfigurable

  • com.intellij.ide.projectWizard.ProjectSettingsStep

  • com.intellij.ide.util.newProjectWizard.SelectTemplateSettings

  • com.intellij.ide.projectWizard.ProjectSettingsStep

  • com.intellij.polySymbols.PolySymbolQualifiedName#getQualifiedKind() - There is a remaining method, getKind(), but I’m not sure it’s a direct replacement.

I checked for Known Breaking Changes, but that doesn’t seem to have any new content for the 2026.1 EAP. I’ve looked at the sources for the EPs/classes specified above, and none of them show any indication of removal/replacement.

Maybe I’m missing something obvious, but I was definitely surprised to see this level of removal version-to-version of things that didn’t seem to be on a deprecate-and-remove path.

Any insights that you can provide are greatly appreciated. If I should just log one or more issues in YouTrack, let me know and I’ll get them going.

2

Could you tell us more? We have not intended to remove any of these extensions and this feels like a bug/misconfiguration in builds.

4

Thank you for reaching out to us.

Could you provide your dependencies in plugin.xml?
If you use something like:
<dependencies>
<plugin id="com.intellij.java"/>
</dependencies>

Сould you add (or replace it with)
<module name="intellij.java.backend"/>

Please, let us know about your results.

It will be added to the breaking changes, sorry for the delay

5

If you use <depends>com.intellij.java</depends> there must be no changes required and everything should stay compatible, let me reproduce the issue with the fresh EAP

6

Please note experimental status of the entire com.intellij.polySymbols package. There could be no migration for some breaking changes there until it stabilizes.

@ApiStatus.Experimental
package com.intellij.polySymbols;
7

I did

dependencies {
    intellijPlatform {
        intellijIdea("261-EAP-SNAPSHOT") {
            useInstaller = false
        }
        testFramework(org.jetbrains.intellij.platform.gradle.TestFrameworkType.Platform)

        bundledPlugin("com.intellij.java")
    }
}

Then declared:

<projectStructureValidator implementation="org.example.javadepplugin.Validator"/>

And

public class Validator extends ProjectStructureValidator {
}

It all compiles and runs as usual. What could be different to your setup?

Once again I want to highlight that there must be no breaking changes in that area, so let’s figure out what is the reproducer so we can fix it.

8

Thanks for all the feedback, guys. That’s reassuring. My project is not Gradle-based for a number of reasons, not the least of which being the significant performance issues of Gradle-based projects on Windows and some incompatibilities on Windows/ARM64 which is my daily driver. That’s why I had to wait for EAP 3 to resolve the issue creating a plugin SDK.

It sounds like perhaps these classes moved around a bit and weren’t added as part of the core plugin SDK as they’d been in the past. That’s my oversight as I generally catch when things are moved into modules or plugins. I’ll find them in a bit once my morning appointments wrap up.

Regarding the polySymbols change, could someone responsible for that area please let me know the right migration path for getQualifiedKind? I ended using that API based on JetBrains’ recommendation to start for some JavaScript/TypeScript behavior that wasn’t possible elsewhere.

Again, I appreciate the quick feedback.

9

Sorry, I’m not responsible for this area, but it looks like it was changed here: https://github.com/JetBrains/intellij-community/commit/c9c2470405541dba1a1616808fac9f514af8d4e7#diff-248622308f6f91094b13e504e37d9ca9de9cb9fc07b6db1ec205e170a4509f13

According to that commit, you may want to try to migrate and use kind: PolySymbolKind instead of qualifiedKind: PolySymbolQualifiedKind.

The other classes are from the intellij.java.ui module, so you would need to have a dependency on the java plugin anyway. If you use <depends>com.intellij.java</depends>, there should be no changes required, and everything should remain compatible. Otherwise, it would be necessary to add explicit dependencies to these modules.

10

It is interesting! How do you add JARs to your classpath for build? Java is multi-modular plugin at the moment

11

Thanks again. I’ve made good progress and it looks like those IntelliJ IDEA-specific new project wizard things are fine now.

One thing that’s odd is that a few things that seem to be IDE-agnostic have been moved into Java-specific artifacts, or perhaps they were always there but it wasn’t obvious because of the Java packaging. I’m specifically talking about the following:

  • com.intellij.codeInsight.daemon.QuickFixBundle where I was using message key remove.suppression.action.family.
  • com.intellij.refactoring.HelpID where I was using constants for the various refactorings that I’ve implemented in my plugin.

Is that expected? Are there IDE-agnostic versions of those to be found anywhere? I can obviously add my own, but it was nice to be able to use the IDE’s where available.

12

Please avoid reusing message keys if possible, we do not really treat them as API and do not track breaking changes there automatically, such as removal of keys

1 Like
13

is a part of intellij.java.analysis.impl module.

is a part of intellij.java.impl module.

I am not sure that there are ide-agnostic versions, because it is used inside java plugin only

14

Yes, that was the question…whether there were IDE-agnostic versions of those same message keys/constants since something like “Remove suppression” seems to apply equally for any language that supports redundant suppression detection and removal (my plugin does for its supported language). However, @yuriy.artamonov‘s comment about not treating message keys as API effectively answers that question. No issues. I’m definitely knocking almost all of these remaining issues out now. Thanks again!