Jar files auto-created and added to classpath on Cursor startup

Support Bug Reports
,
5

Hey, thanks for the detailed report. Great investigation.

But the key point is that this behavior isn’t Cursor-specific. Java tooling like project import, Buildship, and materializing the classpath from org.eclipse.buildship.core.gradleclasspathcontainer into a live .classpath file all comes from the Red Hat Java extension and the built-in Eclipse JDT and Buildship. Cursor doesn’t patch or override that pipeline. You can reproduce the same thing in VS Code with the same extension. The -Djava.import.generatesMetadataFilesAtProjectRoot=false flag you’re seeing is also a standard one from redhat.java.

The three active importers you saw in the logs, GradleBuildServerProjectImporter, GradleProjectImporter, EclipseProjectImporter, are a known conflict point in redhat.java. This looks like a good candidate for an upstream issue.

Things you can try locally:

  • In Settings, check and disable competing importers:
    • java.import.gradle.enabled: true
    • java.import.gradle.wrapper.enabled: true
    • disable java.import.projectSelection or the Eclipse importer if it’s a Gradle project
    • try java.gradle.buildServer.enabled: false or toggle it the other way to see which importer adds the extra jar entries
  • Delete workspaceStorage/.../redhat.java/jdt_ws completely and let the import run again. Sometimes the cache keeps an old .classpath even after the model is cleared.
  • Check whether eclipse.classpath.file.whenMerged is being applied in the opposite direction. Re-sorting can bring entries back if the Buildship container resolves before the merge.

For a proper fix, it makes sense to file an issue here and include your files, .classpath plus the Buildship project preferences:

If you find the specific importer that’s causing it, send it here and we can check if there’s anything we can tweak by default in Cursor.