Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lombok agent doesn't need to be configured if javac is enabled #3875

Open
snjeza opened this issue Nov 26, 2024 · 6 comments · May be fixed by #3877
Open

Lombok agent doesn't need to be configured if javac is enabled #3875

snjeza opened this issue Nov 26, 2024 · 6 comments · May be fixed by #3877
Assignees

Comments

@snjeza
Copy link
Contributor

snjeza commented Nov 26, 2024

Related document - https://projectlombok.org/contributing/lombok-execution-path

@snjeza snjeza self-assigned this Nov 26, 2024
@snjeza snjeza 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 Nov 26, 2024
@mamilic
Copy link

mamilic commented 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
Copy link
Member

rgrunber commented 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/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.

@snjeza
Copy link
Contributor Author

snjeza commented Nov 27, 2024

Apologies for going slightly off-topic, but I’m curious about the benefits of using javac in language server.

See #3875 (comment)

Does javac support method navigation and other quirks that jdt.ls.core provides?

No, it doesn't.

Would it potentially replace jdt.core?

This feature is part of jdt.core.

@rgrunber
Copy link
Member

rgrunber commented Nov 27, 2024

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.

@rgrunber rgrunber removed this from the End November 2024 milestone Nov 28, 2024
@mattreid
Copy link

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
Copy link

Trying again now after updating the expected GH project mapping. Sorry again for the noise upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

4 participants