Cursor cannot be used (fully) with Gradle 9 projects because the vscode-gradle extension is too out-of-date. In Cursor I see latest (as of today) as 3.15.0 (Feb 2024), but the actual most recent release of that extension is 3.16.4 (June 2025).
Why is the version of the vscode-gradle plugin in the Cursor extension marketplace more than a year old?
Steps to Reproduce
Try to use Cursor on any project build with Gradle 9.0.0 using the “Gradle for Java” (microsoft/vscode-gradle) extension.
Expected Behavior
Cursor should work on Gradle 9 projects just as well as is does with Gradle 8.14 projects. Cursor’s extension marketplace should get new releases of the vscode-gradle plugin much faster than with >1yr delay.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Cursor uses Open VSX Registry - Open VSX Registry
Microsoft hasn’t published newer versions of Gradle For Java and pre-release versions na Open VSX Registry
I have created VSIX using the latest Gradle For Java develop branch - https://github.com/snjeza/vscode-test/raw/refs/heads/master/vscode-gradle-3.17.6.vsix
You can install it with View>Command Palette>Extensions: Install from VSIX…
The extension requires Language Support for Java™ by Red Hat pre-release. It is on Open VSX registry so it can be installed from Cursor.
After that, you can try to import a Gradle 9 project.
The only problem is that now I’m stuck on problems with the Oracle “Java” extension. It depends upon on a netbeans module for it’s gradle support, and that module used a class that Gradle 9 removed. The netbeans module issue has already been fixed in their source repo, but it will probably be weeks or months until it trickles all the way down to Cursor. (We cannot use Red Hat’s extension for Java because the eclipse compiler simply can’t handle our large+complex project efficiently.)
I’m sorry that unfortunately I’m not able to spend much more time on this to help.
About our need to use Oracle’s Java extension…
Until the Red Hat Java extension can run the HotSpot compiler, it’s a non-starter for us. I don’t want to try to explain and defend all the reasons for that here publicly. I think most experienced Java experts will understand anyway that there are good sound reasons why some projects might not use ecj. We actually did try to use the Red Hat extension originally, but had multiple major problems with it.
I don’t understand your claim that RedHat’s java language server will use the HotSpot compiler. Can you provide your source where that info came from? When we previously attempted to use Red Hat’s extension for Java, I believe we observed it using the eclipse compiler. Also, the README for the Red Hat vscode-java extension’s project (redhat-developer/vscode-java: Java Language Support for Visual Studio Code) says:
”Provides Java ™ language support via Eclipse ™ JDT Language Server, which utilizes Eclipse ™ JDT, M2Eclipse and Buildship.”
The Java HotSpot VM builds upon Java technology’s cross-platform support and robust security model with new features and capabilities for scalability, quality, and performance. In addition to new features, this version is upward compatible with previous releases.The Java HotSpot VM supports virtually all aspects of development, deployment, and management of corporate applications, and is used by:
Integrated development environments (IDEs) including the Sun Java Studio Tools, the NetBeans open source project, IBM’s Eclipse, IntelliJ IDEA, Oracle JDeveloper, and others.
We’re basically giving up on upgrading to Gradle 9 until both vscode-java and vscode-gradle have released fixed versions to the Open VSX registry. Manually installing fixed VSIX files is fine for testing fixes, but is not a good solution otherwise. Real-world development environments already have a million little development tools details that every team member is forced to deal with, and we’re not willing to add manual installation of VSIX files to that list.
Netbeans 25 fixed support for Gradle 9, and Oracle’s plugin has updated to that. I believe their release 24.1.1 will work with Gradle 9. That should fully unblock us to use Cursor with Gradle 9.0.0. Nice!