(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.

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

Description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions