Start the debugging analysis. What is the order of the classpath for finding the main class, and which jars are involved? #615
Description
- The entire project has approximately 40,000 dependency JARs. If the classPaths are not prioritized for resolution, it will perform particularly slowly.
Activity
Is there a parameter to print the JAR list that resolves the main class?
Hi mozhuanzuojing, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.
Suggestions to improve main-class resolution and startup time
-
Explicitly specify
mainClassandprojectNamein your launch configuration to avoid scanning all workspace projects:{ "type": "java", "request": "launch", "name": "Debug MyApp", "projectName": "my-app-project", "mainClass": "com.example.Main", // ... } -
Use the
classPaths(ormodulePaths) array inlaunch.jsonto list only the JARs needed at startup, so the debugger skips the rest of the ~40 000 dependencies. -
Narrow down your workspace libraries via VS Code settings (
java.project.referencedLibraries) to include only the patterns you care about (e.g.,“**/lib/*.jar”). -
If you’re on a Maven project, use the “Run | Debug” code lens above your
main()method—this will generate a config that includes only your project’s runtime classpath rather than the entire workspace.
Other references with low confidence
-
Wrong classpath at runtime when the maven project is in a folder (Not sure the sequence of DAP requests #584)
Describes how the search engine does a distinct-by–first-found step (so the order jars are indexed matters) and then filters out test-scope entries.
Solution: none yet, but it tracks how classpath entries are ordered.
Wrong classpath at runtime when the maven project is in a folder vscode-java-debug#584 (comment) -
Failed to resolve classpath: xyz (#331)
Explains how the debugger auto-resolves classpath by projectName + mainClass and can be error-prone if those aren’t set correctly.
No performance fix, but highlights the importance of specifying those fields.
Failed to resolve classpath: xyz vscode-java-debug#331
The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!
-
Hi mozhuanzuojing, thanks for reporting this.
Quick analysis of how classpath/main class resolution works:
Main class search (resolveMainClassCore) — only scans source code (IJavaSearchScope.SOURCES), not JARs. This should be fast even with 40k JARs.
Main class validation (getJavaProjectFromType) — uses SearchEngine.createWorkspaceScope() which does search all classpath entries including JARs. This can be slow if projectName is not specified.
Classpath resolution (JavaRuntime.resolveRuntimeClasspath) — must process all classpath entries returned by the build system (Maven/Gradle). No prioritization or shortcutting here.
Workaround: Explicitly setting both mainClass and projectName in launch.json skips the expensive workspace-wide search in step 2, which should help.
That said — could you share more about your scenario? Specifically:
What are you trying to achieve with a project that has ~40,000 dependency JARs? Is this a monorepo or multi-module project?
Is the slowness only on the first launch after clean, or does it persist on subsequent launches?
Are you using Maven or Gradle?
Understanding your use case will help us determine whether there's a meaningful optimization we can make on the debugger side.Thank you very much. The issue is only slow the first time and does not affect usage. I would like to close this matter now.
Reacted by wenytthank you, I will close this issue, once you have the same experience, please reopen this issue or create a new one.
