Provide support for Java 21 #3292
Comments
|
Everything works "fine", but I get this error: 
|
|
@brunoborges indeed, that's the point of this ticket, to provide Java-SE 21 support. |
|
I guess my point is that it works (aka it is already "supported"). It just has this annoying alert |
|
no it doesn't, you can't compile against Java 21 in vscode-java yet. JavaSE-21 is unknown to JDT |
|
VS Code Java depends on Eclipse JDT to provide editor smartness, compilation, as well as new Java version support. Complete Java version support is typically available in JDT within a few weeks of the Java release. Unfortunately complete Java 21 support is currently delayed in JDT until the end of 2023. Basic JDT support for Java 21 compilation exists, however all preview features are currently unimplemented. JEP 12 concerning preview features states that all preview features must be implemented equally alongside standard features before claiming Java support is available. VS Code Java therefore cannot claim support for Java 21 until all Java 21 preview features are implemented in JDT. We are collaborating upstream to get all preview features merged into JDT as soon as possible. |
|
Working well so far for me. Only weird thing is "Configure Java Runtime" is showing 20 for projects using 21: |
|
Why not allow it to use the JDK-21 without preview features? All software has limitations - just don't claim vscode Java plugin has full JDK-21 support. As it is, it doesn't work at all. It says JAVASE-21 is an invalid type. |
|
I am also not sure how anyone is getting it to work - at least with Gradle builds. Gradle builds fine, but in vscode it either can't find the JDK libraries, or it can't find the gradle referenced libraries. So nothing works. |
|
For reference, the following already seem to support Java 21. Oracle's Java Platform extension for Visual Studio Code
|
|
Thanks for the heads-up @cypher256 - the Oracle extension works so much better all around! |
|
@robaho other than Java 21 support, what features do you find work better all around ? |
|
First, the eclipse compiler fails on many generic constructs that javac deals with fine. The creation of pref files, buildship files, project files, classpath files - all which have nothing to do with compiling the project with gradle/maven The oracle extension requires a gradle or maven setup - but you can create a trivial gradle file as a replacement of the “unmanaged project” using the redhat extension. Tbh though I haven’t tried simply opening an arbitrary Java file for editing/viewing. I expect this wouldn’t work well with the Oracle extension. |
I've seen a few of these issues. There are definitely cases where the ECJ compiler may get it wrong, but there's also cases where javac may be wrong.
Since 1.1.0 (End Nov 2021), project metadata files should not be generated in a project's root folder. See https://github.com/redhat-developer/vscode-java/blob/master/document/_java.metadataFilesGeneration.md . |
|
@rgrunber Thank you for all your wonderful contributions.
|
On issue I found with is feature - but it was hard to determine the cause due to the lack of full 21 support - was that if I had multiple branches with different versions of the JDK when I switched between them the redhat extension seemed to get confused about the state. I really liked the unmanaged folder capability but after working with the oracle extension I think auto creating a top level gradle file to use actually works better and is easier to understand what is going on. Seems the extension could manage this. |
Yes - thank you ! |
and what about people who never use gradle, but instead always use Maven? The fact that vscode-java supports folder without build management file is IMO a great features for most people. They can start coding without bothering about build (which is exactly the trend java is taking with direct launch of Java files, support for unnamed class, JEP proposal to resolve other .java files directly...). Then, as the project scales, build can be added progressively just as user likes it (Maven vs Gradle vs Bazel vs...) and vscode-java would just react to that change. |
|
If they are using maven then the maven support is already there. The unmanaged support is basically doing this with eclipse project structures behind the scenes - no reason the gradle file can’t be hidden as well. |
|
OK, but then if the gradle file is hidden, what does it change to user whether it exists or not? The Eclipse project structure is sufficient to edit code, what would a hidden Gradle file add? |
@rgrunber I'd say it's not about whether one or the other edge case compiles or is spec-compliant. It's about the fact that NetBeans' language server is much, much more resilient to errors in the code. 99% of the time, my code has at least 1 error, but that's ok, because 98% of the time, NetBeans is still able to give me code completion, meaningful errors, etc. On the other hand, this language server is very sensitive to errors: even a simple syntax error in method A, like a missing semi-colon, could cause code completion etc. to break down in method B. And of course there's the fact that NetBeans' language server supports the latest JDKs, even early-access ones. I understand it's incredibly hard to develop an independent compiler implementation like ECJ, especially since the new JDK release cadence, but as a developer I want something that "just works" with the latest & greatest. @brunoborges Microsoft should really switch the Java language server in its extension pack from Red Hat's to Oracle's (which has existed as NetBeans' for 3 years already). In my experience it has a way, way better editor experience and as mentioned it always supports the latest & greatest JDKs |
That's is a surprising statement as JDT parser has always been fault-tolerant (before Javac and NetBeans started to consider it) and thus capable of providing further assistance to such cases. |
|
Agreed. Also, it would be nice if the pre-release version in the VSCode extension market is updated to 1.25.1. (Currently it is 1.24.x and it does not work with JDK 21) |
|
There are some legal concerns that need to be cleared before releasing a subpart of Java 21 support. vscode-java uses Eclipse JDT which implements the Java compilation specification (JLS) and it's not legally clear whether one can release only a subpart of the Java language and still say it's "Java". The term "Java" is a trademark and comes with constraints on its usage, compliance to spec is one of those constraints; we'll soon be discussing with Eclipse Foundation whether supporting only a subset of the spec is fine (so we can just ship whatever we have) or whether it violates the trademark (so we'll have to wait more). |
Thank you for the information. Is there some recent development that has caused this legal concern? |
The particular case here compared to former Java releases is that until now, Eclipse JDT always managed to release full support for the newer Java version (ie all JEPs supported) at once, so it was Java XY compliant. Here it's not the case, the support for Java 21 in JDT is only partial, so it's not fully Java 21 compliant, and this is per se a legal concern of how to communicate "partial support" without breaking some rules of the Java™. |
|
Can't you call it a beta and move forward ? :) |
|
@snjeza , we have approval to integrate the existing Java 21 support contributions. Please rebase the PRs, and we can hopefully merge today. |
|
@rgrunber I have rebased them. |
|
Thank you Roland for moving this forward. |
|
hi! i am still facing this problem, how can i fix this?
"java.configuration.runtimes": [
{
"name": "JavaSE-21",
"path": "D:/ProgramFiles/Eclipse Adoptium/jdk-21.0.1.12-hotspot/",
"default": true,
},
],
|
|
@goyalyashpal you need to install the pre-release version of vscode-java |
|
thanks for the swift response 😇 :humble:
does that contain additional telemetry or data collection etc? asking as many other tools did that without any special intimation. and the author responded with "you agreed to use beta - it's obvious that it collects data to collect bug reports, ..." |
|
There's no special telemetry for pre-releases. |
|
awesome, thanks a lot. :)
edit:
the vscodium didn't show the prerelease icon beside the extension in the list
nor any mention in description header... i was just about to post this, then
voilla, smth happened and it appeared lol
lesson: vscodium (open-vsx) has prereleases too :)
https://open-vsx.org/vscode/item?itemName=redhat.java
https://marketplace.visualstudio.com/items?itemName=redhat.java
Fred Bricon wrote:
…
There's no special telemetry for pre-releases.
We're collecting more performance data since last release, but if you
disabled telemetry collection (|telemetry.telemetryLevel|:|off| or
|redhat.telemetry.enabled|:|false|), we're still abiding by those
settings.Message ID:
***@***.***>
|
|
I think it would be beneficial for future releases to have newer Java versions supported earlier, as that might be the cause for backing up from Vs Code its self, as developers want to play with new thi gs as soon as possible. |
|
@milic-marko All those pieces of software involved in the development of vscode-java are open-source project. Those have failed to meet the deadline because of not enough contributors were actively developing new Java version support in Eclipse JDT (because it's actually a lot of not trivial work for a handful of maintainers). So if you want to help making Java support provided faster, please consider contributing to Eclipse JDT in a way or another to help spreading the workload across more maintainers. |
|
@mickaelistria , Actually didn' t know that. Will keep an eye on Eclipse JDT, and try to contribute. Thank you for quick reply. |
|
Any ETA for v1.25.0? Is there any place where we can see the roadmap for the project? cc: @rgrunber |
|
Thursday, Nov 30th. |
|
I want to emphasize this release will not include Java 21 preview features, as those have not been added in upstream JDT yet. So, no unnamed classes, nor unnamed variables nor string templates support yet. |
|
Thank for the info @fbricon |
The related Eclipse PR - eclipse-platform/eclipse.platform.releng.aggregator#1325
Java 21 support
Java 21 Marketplace entry
The text was updated successfully, but these errors were encountered: