The state of plugin development on Windows

IntelliJ Platform
1

Hello, I was wondering if any of you develop plugins on Windows. I ask this question because, it has become a pain (at least on my computer :sweat_smile:):

Because of that, Iā€™m sticking to the intellij-platform-gradle-plugin v2.1.0, which is quite old. Iā€™m sticking to this version because itā€™s not affected by these issues. Unfortunately, because of that, I canā€™t target 2025 IDEs with this version. This is will be a problem for me soon, as Iā€™m using more and more deprecated APIs, and I absolutely need to switch to 2025 IDEs to use newer APIs. I mean, my plugins are compatible with 2025 IDEs, but I canā€™t build against 2025, nor test with a 2025 sandboxed IDE.

So, I donā€™t know. What should I do? I have a VirtualBox VM with Linux, but this is not ideal.
This is why Iā€™m trying to alert JetBrains about the poor state of plugin development on Windows. I donā€™t understand why this is not a priority. At least, this is my feeling.

Thanks for reading.

3

I use Windows ā€“ specifically on ARM64 ā€“ as my daily driver for plugin development. However, my plugin doesnā€™t use a Gradle build. That obviously comes with its own set of challenges, but it does avoid the ones youā€™ve cited here.

I experienced some of these when working on an open source plugin for a few months that does use a Gradle build, specifically the issue with jar locking. At some point I found a way to avoid that issue, but I honestly donā€™t remember the solution. Also, the Gradle plugin SDK doesnā€™t work well on Windows/ARM64. I had to comment out the following in build.gradle.kts or the build would fail with some known issue on that OS/arch combination:

kotlin {
    jvmToolchain {
        languageVersion = JavaLanguageVersion.of(17)
        vendor = JvmVendorSpec.JETBRAINS
    }
}

I donā€™t have to do that on my Windows/x64 machine, but itā€™s so much slower than my Windows/ARM64 machine that itā€™s worth the workaround(s).

So thatā€™s probably not at all helpful, but in the spirit of ā€œmisery loves companyā€, Iā€™ve also seen issues with plugin dev on Windows. I havenā€™t ever tried plugin dev on Mac or Linux, though, so I donā€™t know if those have their own issues.

4

Yeah, sometimes I think about making my own Maven build.
Or, take the Gradle platform plugin v1 and fix it in order to run 2025+ IDEs in sandboxed mode. I still have some plugins (8, all my free plugins) using this version, and they are built very quickly.

I tried to look at the source code of the Gradle platform plugin v2 several times, but itā€™s too complicated for me. I canā€™t invest a lot of time in this project. Actually, I donā€™t understand why JetBrains allocates so few people to it. It deserves an entire team. Jakub deserves a lot of credit for doing all the work. Seriously.

I donā€™t know if JetBrains is aware of that. Actually, itā€™s like everything is getting worse.

  • plugin dev on Windows is a pain
  • more frequent IDE releases, and the marketplace that will unset the until-build flags in order to encourage us to support EAP IDEsā€¦ (even if Junie does not support EAPs :rofl:)
  • this discourse server is now essentially a community-effort. But, we can now pay for the JetBrains support (I canā€™t afford that, my incomes are too low). Honestly, this is the best way to kill the community.

I know JetBrains is afraid of VSCode. The new user interface looks like VSCodeā€™s, Iā€™ve read the JetBrains surveys comparing IJ to VSCodeā€¦ Despite this, JetBrains still has a good community, for now. It should invest in this community rather than looking elsewhere (or invest 1% less on AIs).

5

Hey, Jonathan!
First of all ā€” thanks for your kind words! :slight_smile:

Unfortunately, youā€™re right ā€” developing on Windows is a bit harsh due to the filesystem issues you mentioned that became visible as soon as the IntelliJ Platform Gradle Plugin started using Plugin Verifier libraries for processing zips/jars and building plugins and modules dependencies tree.

I still believe that Plugin Verifier can be improved, like not loading everything at once when reading and parsing the IDE directory and requesting some resources lazily (cc @robert.novotny).

To slightly limit the FS operations on Windows, you may turn on the IntelliJ Platform artifact custom caching with:

dependencies {
  intellijPlatform {
    create(type, version) {
      useCache = true
    }
  }
}

Iā€™ve also already investigated the JUnit4 lock. It happens because the guest IDE loads sandbox resources into its process and keeps them open. Rebuilding the project fails at this point because Windows wonā€™t let you do anything with that open file. Iā€™ll get back to this story soon.

6

Just a question, did someone try to use ReFS to develop? it should solve some of the issue and be more targeted to developers than NTFS

7

@robert.novotny @jakub.chrzanowski
Just to say plugin development is still painful on Windows, even with the latest platform plugin and IJ 2025.3. The junit4 jar is still locked, and performance is terrible.
Do you have some news to share? Can we expect some improvements? Thx.

8

Hi @jakub.chrzanowski Iā€™m from dev team of GitHub Copilot plugin for JetBrains IDEs. And I also find the performance issue when dev on Windows PCs. May I also ask if you happen to get some progresses on the improvements? I also created an issue here: https://youtrack.jetbrains.com/issue/IJSDK-2687/Performance-issue-to-develop-plugin-with-runIde-task

Thanks!

9

Duplicating issues on YouTrack, where it says you shouldnā€˜t, wonā€˜t help.

Your report says youā€˜re using 2.5.0 of the Gradle IntelliJ plugin. The latest is 2.10.5 and AFAIK there have been quite a few improvements to make things better compared to that old version.
In my experience, Windows is the worst platform for plugin development, but I recently used Windows 11 with 2.10.x and it was okay.

10

Interesting :+1:, because Iā€™m still on Windows 10 and I recently migrated from the platform plugin 2.1.0 to 2.10.5, just to work with 2025 IDEs.
I will try on Windows 11, just to see.

For IDEA-376932 (the junit4 jar is locked), Iā€™m using a workaround: instead of using Gradle Run Configurations, Iā€™m using the command line or Shell Script Run Configurations, which are not affected. There is one downside: itā€™s not easy to debug a sandboxed IDE.

Unfortunately, Iā€™m still impacted by the slow builds (x2 times slower, and itā€™s reproducible on the intellij-platform-gradle-pluginā€™s Windows CI). I will see if Windows 11 can help.

At least, I can work with the platform plugin v2.10.5, but itā€™s still frustrating.

@jiec-msft I think your problem is different. I think we can continue here: runIdeTask Takes 20-40 Seconds on Windows 11 Due to IDE Instance Recreation Ā· Issue #2071 Ā· JetBrains/intellij-platform-gradle-plugin Ā· GitHub
As suggested, you should upgrade your intellij platform gradle plugin. If it doesnā€™t help, sharing a sample project and a build scan would help a lot.

11

Just tested on W11 with a JDK21, Gradle 8.14.3 and 9.2.1, but I observed no improvements :sad_but_relieved_face:

12

The IntelliJ Platform Gradle Plugin 2.15.0 is now available.
This release was focusing on improving the performance and contains improvements not only in the Gradle plugin itself but also dependent Plugin Verifier library.

Please switch to this version and check if you noticed anything. Thanks!

Changelog: Release 2.15.0 Ā· JetBrains/intellij-platform-gradle-plugin Ā· GitHub

13

On my main plugin project, on Windows, build+test is ~10% faster, which is good to take :+1:, but itā€™ still very slow.
Iā€™d like to test with with GitHub - JetBrains/intellij-platform-plugin-template: Template repository for creating plugins for IntelliJ Platform Ā· GitHub in order to compare numbers with an official sample project (mine is too much customized, and private), but how do we change the intellij-platform-gradle-plugin version? The libs.versions.toml is gone. I tried to update org.jetbrains.intellij.platform.settings to 2.15.0 in settings.gradle.kts, but I get this error:

* What went wrong:
org/jetbrains/kotlin/gradle/tasks/KotlinJvmCompile
> org.jetbrains.kotlin.gradle.tasks.KotlinJvmCompile

* Try:
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.

* Exception is:
java.lang.NoClassDefFoundError: org/jetbrains/kotlin/gradle/tasks/KotlinJvmCompile
        at org.jetbrains.intellij.platform.gradle.plugins.project.IntelliJPlatformBasePlugin$apply$7.execute(IntelliJPlatformBasePlugin.kt:606)
        at org.jetbrains.intellij.platform.gradle.plugins.project.IntelliJPlatformBasePlugin$apply$7.execute(IntelliJPlatformBasePlugin.kt:523)
        at org.gradle.api.internal.plugins.DefaultPluginManager$2.execute(DefaultPluginManager.java:261)
        at org.gradle.api.internal.plugins.DefaultPluginManager$2.execute(DefaultPluginManager.java:258)
        at org.gradle.internal.code.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:124)
        at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction$1.run(DefaultCollectionCallbackActionDecorator.java:109)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:30)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:27)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:67)
...
14

I tried to use the template v2.4.1 (most recent version is 2.5.0), but once updated the plarform plugin to v2.15.0, I canā€™t deactivate gradleā€™s caching.
Iā€™ve set

org.gradle.caching=false
org.gradle.configuration-cache=false

but cache is still used. I mean, the first build is still too slow (but a bit faster), then subsequent builds take 1s (many tasks are skipped). I canā€™t say if this is different with the template v2.5.0 as I cannot change the platform plugin version when using the template v2.5.0. Also, buildPlugin works, but test fails.

Anyway: my results on Windows with the template v2.4.1 with gradlew clean buildPlugin --no-daemon --scan:

For each platform plugin, I ran gradlew clean buildPlugin --no-daemon --scan three times and I kept the fastest build. And, again, I was not able to run the test task.

15

@jonathanlermitage.1 The KotlinJvmCompile is now fixed in the main branch. I missed the point that the class I used when building the Gradle plugin is something different than what is eventually used in the project.

Thatā€™s the correct way, yes.

As for timings ā€” the largest difference happens when you build project with a bundled plugin added, like bundledPlugin("com.intellij.java")
This is because Plugin Verifier does some filesystem readings, which take time on Windows.

I probably found another possibility for that by itroducing a cached index dump. The first run against a specific IntelliJ Platform still may take a while, but any successive ā€” after building that index ā€” should go way faster.

Can you please try the 2.15.1-SNAPSHOT?

16

With the platform plugin 2.15.1-SNAPSHOT: 13s - Build ScanĀ® | Develocity
The configuration phase now takes ~6s instead of ~10s :+1:
Iā€™ve noticed the same improvement in my own plugin projects.