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.

1 Like
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