You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Lombok agent doesn't need to be configured if javac is enabled #3875
changed the title [-]Lombok agent doesn't need to be configured if java.jdt.ls.javac.enabled is on[/-][+]Lombok agent doesn't need to be configured if javac is enabled[/+]on Nov 26, 2024
Apologies for going slightly off-topic, but I’m curious about the benefits of using javac in language server. I noticed this feature in the latest vscode-java version. Does javac support method navigation and other quirks that jdt.ls.core provides? Would it potentially replace jdt.core?
(TL;DR : faster language feature adoption, behaving closer to what users see when they run a compile via. CLI, and being able to swap ECJ/javac with no noticeable difference in features)
The 2 main motivations for javac support were :
Since Eclipse has its own compiler (ECJ), it must also have its own implementation of bytecode generation. Being able to just use javac's immediately simplifies the development of new language features, particularly as the frequency of Java language features per release increases (along with the frequency of releases). This means we'll be able to support new Java versions faster
javac, ECJ, and the actual Java language specification all have their quirks. There are cases where they all "say" something different, but ultimately users consider javac to be the final word. In other words, if javac can compile it, and ECJ opts to emit a valid error, it's still considered a bug from the user's point of view. Having javac support can fix many of these issues.
There is (mostly) a separation between the internals generated by ECJ and the API provided by JDT Core that JDT-LS uses. We've been improving this to make it easy to swap out ECJ with javac. The underlying API remains the same. So yes, the goal is to support everything (code actions, completion, search, etc.). In fact the AST model is pretty good as of now, and most code actions/diagnostics do just work. We're working on improving completion support, and indexing as well. The remaining gaps are in performance and just handling reliability in various cases.
Does javac support method navigation and other quirks that jdt.ls.core provides?
No, it doesn't.
If @mamilic meant : "Will the javac feature support method navigation and all the features JDT-LS provides", then yes, that's the goal, but on its own, javac is just a tool for compilation. All those features come from making requests to the JDT Core API.
Apologies for the noise, you can ignore this, but I'm adding a comment here upstream to see if the rest of the issue metadata will then sync downstream. Thanks for the heads up @rgrunber.
Activity
[-]Lombok agent doesn't need to be configured if java.jdt.ls.javac.enabled is on[/-][+]Lombok agent doesn't need to be configured if javac is enabled[/+]mamilic commentedon Nov 27, 2024
Hi @snjeza,
Apologies for going slightly off-topic, but I’m curious about the benefits of using javac in language server. I noticed this feature in the latest vscode-java version. Does javac support method navigation and other quirks that jdt.ls.core provides? Would it potentially replace jdt.core?
rgrunber commentedon Nov 27, 2024
(TL;DR : faster language feature adoption, behaving closer to what users see when they run a compile via. CLI, and being able to swap ECJ/
javacwith no noticeable difference in features)The 2 main motivations for
javacsupport were :javac's immediately simplifies the development of new language features, particularly as the frequency of Java language features per release increases (along with the frequency of releases). This means we'll be able to support new Java versions fasterjavac, ECJ, and the actual Java language specification all have their quirks. There are cases where they all "say" something different, but ultimately users considerjavacto be the final word. In other words, ifjavaccan compile it, and ECJ opts to emit a valid error, it's still considered a bug from the user's point of view. Havingjavacsupport can fix many of these issues.There is (mostly) a separation between the internals generated by ECJ and the API provided by JDT Core that JDT-LS uses. We've been improving this to make it easy to swap out ECJ with
javac. The underlying API remains the same. So yes, the goal is to support everything (code actions, completion, search, etc.). In fact the AST model is pretty good as of now, and most code actions/diagnostics do just work. We're working on improving completion support, and indexing as well. The remaining gaps are in performance and just handling reliability in various cases.snjeza commentedon Nov 27, 2024
See #3875 (comment)
No, it doesn't.
This feature is part of jdt.core.
rgrunber commentedon Nov 27, 2024
If @mamilic meant : "Will the
javacfeature support method navigation and all the features JDT-LS provides", then yes, that's the goal, but on its own,javacis just a tool for compilation. All those features come from making requests to the JDT Core API.mattreid commentedon Dec 16, 2024
Apologies for the noise, you can ignore this, but I'm adding a comment here upstream to see if the rest of the issue metadata will then sync downstream. Thanks for the heads up @rgrunber.
mattreid commentedon Dec 18, 2024
Trying again now after updating the expected GH project mapping. Sorry again for the noise upstream.
rgrunber commentedon Jan 16, 2025
(sorry for noise, testing something)