[Question] Why not contribute to VSCodeJava extension

[gayanper]

First of great that you provide Javac base extension which will be closer to new java features. But was there any reason not working together with VSCodeJava on adding new features into JDTLS rather than spinning a new extension with new LS ?

I'm more thinking about the ambiguities that will build up in VSCode extension choices for new Java developers. Because some of the plugins might only work with VSCodeJava and some with only Oracle Extension like the current Micronaut and GraalVM extensions.

[pron]

If you mean the extension "Language Support for Java by Red Hat" that's based on Eclipse then:

1. We weren't happy with the experience Java programmers were getting in vscode, and the NetBeans LS seemed to have better potential.
2. We needed a language server that's based on the OpenJDK JDK — as that's our main project and what our people know best — and the Eclispse one isn't (e.g. this means that once we add a feature to javac we don't need to add it to another compiler).
3. We have much more institutional knowledge of and experience with NetBeans than Eclipse.

[overtomanu]

@pron For developers using spring boot extension in vs code, the language support by redhat is a dependent extension. For time being, it seems to be having below issue

https://github.com/redhat-developer/vscode-java/issues/2643#issuecomment-1789171004

It will be great if there is any guide/steps to replace that extension and use spring boot vscode extension with this extension. This will definitely help in wider adoption of this extension.

[gayanper]

@pron thanks for explaining. I also see the potential, but I do see some shortcomings as well in current state for wider audiences

• support for springboot extensions as already mentioned

• support for libraries like lombok

• support for grpc code generators

Also some documentation about how to build extensions which will extend the current extension functionality both at editor side and language server side.

[akaroml]

If you mean the extension "Language Support for Java by Red Hat" that's based on Eclipse then:

1. We weren't happy with the experience Java programmers were getting in vscode, and the NetBeans LS seemed to have better potential.
2. We needed a language server that's based on the OpenJDK JDK — as that's our main project and what our people know best — and the Eclispse one isn't (e.g. this means that once we add a feature to javac we don't need to add it to another compiler).
3. We have much more institutional knowledge of and experience with NetBeans than Eclipse.

@pron Check this out eclipse-jdtls/eclipse.jdt.ls#2388

Discussions around replacing ECJ with JAVAC are happening at JDT.LS side. I see folks experimenting already. Like @gayanper mentioned, there are quite a few tools built on top of JDT. The combination of JAVAC+JDT+Rich Ecosystem looks promising.

[gayanper]

@pron coming back to what you mentioned, how much os LS features are updated with new JDK Languages features ? Is it only the compilation part of the new features or does it covers

• Code Completion
• Debugging

as well ?

[gayanper]

And also @pron What is the difference between

• https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java
• https://marketplace.visualstudio.com/items?itemName=ASF.apache-netbeans-java

[pron]

@gayanper

In some cases, changes to javac/JDI mean an automatic improvement to code completion and debugging, and in other cases some extra work needs to be done in the LS, but the idea is that relevant OpenJDK components, be they javac, JDI, or others, will be well-integrated with the LS. The developers of OpenJDK have been maintaining the language support in the NetBeans backend for many years.

As for the difference between the two extensions, they're built from the same codebase, but 1. may contain different modules, and 2. the client may be different.

[lahodaj]

@gayanper, purely regarding lombok. While I would not recommend or encourage use of lombok, among other things because it uses non-public javac classes, which is causing issues, lombok is plugged into javac as an annotation processor (AFAIK). So, as long as lombok supports the version of javac that is in the backend (which is ~JDK 21 javac currently), the need for explicit "support" for it should be small. I just tried a trivial project with lombok 1.18.30, and it seems to work somehow (not really an expert on lombok, though). The same applies to most projects that use annotation processing (esp. to those that use annotation processing correctly), the need for some explicit "support" for these projects should be small(ish).

[gayanper]

@pron @lahodaj any plans to support inline breakpoints support for adding lambda breakpoints which will enable the developer to suspend the program at chosen lambda on a line instead of on the whole line and on all lambdas on that line ?

[pron]

To me that sounds like a new issue that you're welcome to file.

[gayanper]

On more question about Contributions. Looking at the repository I don't see the language server code, I assume most of features might be something that ends in the language server or debug adapter. So is there a guide how to edit the langauageserver/debugadapter projects ? Could we using the same vscode extension to load those projects and work with as well ?

[pron]

As the announcement said:

The language server will continue being developed as part of the Apache NetBeans project, and Oracle will continue contributing to that project as we have done since contributing NetBeans to the Apache Software Foundation, but the VS Code extension (the client side) will be developed in a separate open source project.

So this repository is only for the client and for the configuration of the NetBeans build (to select the desired modules on the server side), but the language server itself is developed in the Apache NetBeans project.

[anthonyvdotbe]

1. We weren't happy with the experience Java programmers were getting in vscode, and the NetBeans LS seemed to have better potential.

potential being the keyword here, because in its current state it's just a constant source of frustration for me (which is surprising, because I was pretty happy with Language Server for Java by Apache NetBeans and was a very happy NetBeans user before). And Red Hat's LS isn't an option if you want full Java 21 support

[Achal1607]

Closing this issue due to inactivity. If you have any further questions please feel free to reopen it.

[mickaelistria]

Just for fresher news: As mentioned by @akaroml , since last year, Red Hat and Microsoft have collaborated on allowing Eclipse JDT to rely on Javac as backend for parsing/resolution/compilation instead of ECJ. This has been a pretty interesting work for us, and we are happy to report some good results and progress. This was recently announced more widely at https://devblogs.microsoft.com/java/annoucing-javac-support-in-visual-studio-code-java/ during a talk at last EclipseCon where we shared some demos and details about current and expected state: https://www.youtube.com/watch?v=TtRbOuyTwZg (note that this comment is not intended to change anything to this javavscode project but more to add some fresher news to this still interesting discussion)