VS Code - Support the Oracle Java Platform Extension

[ThomasVitale]

Expected Behavior

Oracle has recently introduced a Java Platform Extension for Visual Studio Code. It would be great if the Spring Boot Tools extension could work with it rather than requiring the Red Hat Language Support for Java extension. Perhaps there could be a way to support both and dynamically pick the extension installed in the workspace, so that users can decide what to use.

Current Behavior

The Spring Boot Tools extension doesn't work with the Oracle Java Platform Extension, which currently means it's not possible to work with Spring Boot applications on Java 21.

Context

The Oracle Java Platform Extension has the ability to always support the latest Java versions, including preview features (since it's based on javac). At the moment, it's the only VS Code extension which supports Java 21. Spring Boot Tools depends on the Red Hat Language Support for Java extension, which doesn't support Java 21 yet (pull request in progress which will add support for the stable features in Java 21: https://github.com/redhat-developer/vscode-java/pull/3314#issuecomment-1758462219, thanks @cypher256 for the heads-up). Preview features are planned to be supported at the end of the year based on the needed changes in the upstream Eclipse JDT. As a result, it's not possible to run Spring Boot applications with Java 21 at the moment when using Visual Studio Code and extensions from the Marketplace.

[cypher256]

For reference information, Red Hat Java test version excluding Java 21 preview features https://github.com/redhat-developer/vscode-java/pull/3314#issuecomment-1758462219

Spring Boot Tools Java 21 worked.

[ThomasVitale]

@cypher256 thanks for the info. I can see that pull request will introduce support, looking forward to it being merged! I have updated the issue description with a link to the pull request.

[zhoujian-official]

It will be nice if users can choose to use which java language support extension (redhat or oracle)

[martinlippert]

Independent of which Java version is supported by which Java tooling extension for VSCode, it would indeed be good if the Spring Tools extension for VSCode could work with both and would not require on specific Java tooling to be installed.

I see two fundamental challenges here that we would have to solve:

• the Spring Tools extension relies on some Java tooling to be around to resolve projects and to answer specific questions about some types. For that purpose, the Spring Tools contribute (at the moment) an extension to the Java language tooling from RedHat, so that both tooling extensions can exchange this information (basically via specific custom commands). @BoykoAlex provided some good insights and details in the discussion around supporting NeoVim as a client (https://github.com/spring-projects/sts4/issues/1128#issuecomment-1775237811, https://github.com/spring-projects/sts4/issues/1128#issuecomment-1775278971). In case we want to support the Oracle Java language tooling for VSCode, we would have to find a way to get this information from the Oracle Java extension (or a way to enhance that extension ourselves from the outside, as a did for the RedHat Java language tooling extension).

• to make sure that users don't install the Spring Tools extension without a proper Java tooling extension (which would turn the Spring Tools extension useless), we have the dependency to the Java language tooling from RedHat in place, so that the Java tooling is in place once the Spring Tools got installed. If we want to allow users to use a Java tooling of their choice that are supported by the Spring Tools, it would be good to define a dependency to those Java extensions with an "either or" relation, which isn't possible at the moment (at least not to my knowledge).

@ThomasVitale Do you have insights and thoughts specifically around the first point raised here? I think that is the most important piece of the puzzle to solve first. WDYT?

[ThomasVitale]

@martinlippert thanks for the quick answer. It would indeed be great if it could work with both.

I agree about the importance of the first point. The details shared by @BoykoAlex are interesting for better understanding the problem. I don't have specific opinions about how to address this at the moment.

I'm not much familiar with the internals of the Spring Tools, but I was wondering if the additional commands required to make the integration with an underlying Java tool work are something very specific to the Spring Tools or if they could be useful to other tools that would like to build on the Oracle Java extension. In case of the latter, perhaps the Oracle Java project might be interested in collaborating on adding the additional endpoints.

[martinlippert]

@ThomasVitale I think the commands that are used by the Spring Tools are not extremely specific to the Spring Tools, they could be useful for other extensions as well. It would basically allow other extensions to obtain classpath details for projects.

In case you are interested here, we would be happy to provide further feedback and discuss details anytime. If you have a concrete proposal for those commands that might work for you, feel free to share that anytime.

[martinlippert]

One additional side note here: While the Spring Tools extension is pretty independent of the exact Java language version that is used within projects, we internally use the JDT Java Parser implementation to analyze code, so we somewhat depend of that shipping support for a specific Java version.

Changing this (replacing the internal Java source code parsing) with the javac parser would be possible, but quite some effort, so nothing that we plan doing anytime soon. We hope for JDT to be faster in adopting Java language changes going forward, I think. Interesting approaches are being discussed in this area anyway.

[martinlippert]

Any news on this from your side @ThomasVitale ?