Repository navigation
Suggestions for VSCode's Support for Java Language #1423
Description
Activity
Yep, it's really annoying as CTO trying to advocate VSCode for java/maven/spring projects, because it becomes a nightmare
Hi XS (@tonycody), 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
-
Centralize JDK configuration
Use the built-in settingjava.configuration.runtimesin your workspace’s.vscode/settings.jsonto declare all available JDKs (with names and paths). All Java extensions (language server, debugger, Maven/Gradle support) will pick up these entries automatically.
Documentation: https://code.visualstudio.com/docs/java/java-configuration#_java-runtime -
Project-level settings
Commit the.vscode/settings.jsonfile into your repo so everyone on the project shares the same JDK choices and doesn’t need to reconfigure per extension. -
Use the Java Extension Pack
Install Microsoft’s Java Extension Pack to get language support, debugger, Maven/Gradle, test runner, and more, all designed to work together. -
Settings Sync
If you frequently switch between machines or projects, enable VS Code’s Settings Sync to carry your JDK configurations across environments: https://code.visualstudio.com/docs/editor/settings-sync -
File a feature request
For a true “core” Java extension that exposes a single JDK selector API, please open a feature request in the vscode-java repo so the team can track it.
Labels:
- enhancement
- feature-request
Duplicate of existing issues: none
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!
The support for Java development in VSCode feels scattered without a core organization to regulate the development of other extensions generated for Java. The extensions available for Java in VSCode seem to be doing their own thing, and while some could define common standards to follow, there is no organization to establish that. As a result, each extension feels like a new entity. Even the configuration of the JDK cannot be unified.
JetBrains IDEA is also based on extensions, and many of its features are supported by different extensions. However, these extensions collaborate and embrace the parts that can be unified. Thus, IDEA is relatively more user-friendly.
For example, IDEA provides a unified JDK version selection option at the project level for users to choose from. The compilation extensions can select the JDK specified by the project rather than specifying a JDK version separately. The Maven plugin operates similarly when selecting the JDK, allowing direct selection of the JDK version chosen by the project.
The JDK that these extensions rely on can be specified uniformly, rather than configured separately.
The support for each language in VSCode should start with Microsoft defining a standardized core extension. In the case of the Java language, Microsoft should first define the configuration for the project's JDK. Other newly developed extensions that require a JDK should obtain this JDK option from the core extension.
There should be control over these global elements. Otherwise, every time a user installs an extension, they have to configure the JDK again. Even if configuration is manageable, the problem arises when a user's project needs to switch JDK versions. At that point, all Java extensions would have to re-specify the JDK configuration.
If the cohesion of these extensions is not considered globally, VSCode's development for the Java language will never improve, and no one will use VSCode to develop Java applications.
It is strongly recommended that Microsoft conduct in-depth research on the relevant features of JetBrains IDEA and draw from its more mature solutions to design within VSCode.