javac vs ecj performance

[jbellis]

Hi all,

I'm building the Brokk AI coding platform (https://foojay.io/today/brokk-for-java-developers/) and one of my pain points is waiting for builds to validate the LLM's edits. (Currently we're just running cmdline gradle/mvn/etc and inspecting the results.)

I thought that using ECJ via JDT might allow us to perform faster incremental builds, but it looks like jdt-ls and vscode-java are moving away from ECJ and towards javac.

(1) Is the dom-with-javac README up to date? (specifically, completion and search/match not yet working)
(2) Is the goal to eventually give jdt/javac the same incremental compilation speeds as jdt/ecj? Or are the compatibility advantages so overwhelming that speed is a secondary consideration?

[mickaelistria]

Hi,

validate the [...] edits

You don't really need to care about the underlying compiler for that. You can just use the regular higher-level JDT APIs such as ASTParser on the new code to validate some code. This ASTParser will delegate to ECJ by default, or Javac is configured so; but your code wouldn't have to deal with one or the other directly.
You can also consider using the ASTRewrite operations which are already used by refactorings to ensure the edits it creates are viable.

it looks like jdt-ls and vscode-java are moving away from ECJ and towards javac.

Kind of yes; this is indeed the goal to prefer usage of Javac over ECJ in JDT-LS and VSCode-Java (and even JDT/Eclipse IDE later). But ECJ is still likely to remain and work fine for some time. And the integration we're working on is relatively low-level as explained above, so that users and consumers don't really need to care.

Is the dom-with-javac README up to date? (specifically, completion and search/match not yet working)

Not really and thanks for ringing a bell; I'll update it right after this answer ;)
Completion and search are working, but with known bugs and limitations that we are still working on fixing. There is no fundamental blocker, it's just a ton of corner cases to handle better.

Is the goal to eventually give jdt/javac the same incremental compilation speeds as jdt/ecj?

The incremental build is a feature provided by higher-level JDT to compute the smallest set of files to compile; increment by increment. The underlying compiler is invoked for each increment. The incremental build in JDT does work whichever compiler is used under the hood, as long as the compiler integration with the builder is well implemented; and Javac one is well implemented as far as we know.

Or are the compatibility advantages so overwhelming that speed is a secondary consideration?

Partly yes; but still we do consider that performance is an important criterion for going mainstream. So while it's not the very first goal, it's one of the goals that are considered before considering Javac backend for JDT production-ready. We've already created various optimizations here and there that often make Javac backend on par with ECJ performance-wise; but there are still corner-cases...

[jbellis]

Thanks, Mickael!

The incremental build is a feature provided by higher-level JDT to compute the smallest set of files to compile; increment by increment

Interesting, this shows a gap in my mental model of the stack here. I was under the impression that Eclipse's fast builds were at least partly due to ECJ providing necessary features that javac does not have. Is it more accurate to think of it as "gradle's incremental build features, only built into JDT?"

We've already created various optimizations here and there that often make Javac backend on par with ECJ performance-wise; but there are still corner-cases

To be clear, these are optimizations in JDT? Or optimizations in javac that you are upstreaming?

[mickaelistria]

I was under the impression that Eclipse's fast builds were at least partly due to ECJ providing necessary features that javac does not have

There are some features that ECJ has by default (such as caching dependencies or other often accessed data that is already available in the IDE model) which are not available by default in Javac. But often, with Javac, we can find a flag allowing some more "IDE-friendly" behavior, or we can override some bits of logic to plug-in some caching or proxy strategies that make work more fluently in the IDE.
But there is not 1 killer-feature in ECJ that seems impossible to have when using Javac instead, it just requires some tweaks here and there to be on par.

Is it more accurate to think of it as "gradle's incremental build features, only built into JDT?"

Yes, I think so.

To be clear, these are optimizations in JDT?

There are optimizations in the JDT integration of Javac (this Git repo).

Or optimizations in javac that you are upstreaming?

So far, we've never faced a case where Javac itself had to be optimized; we found some glitches that we reported and helped fixing; but nothing about performance. The performance improvement we enable are usually done by overriding some components/services used by JDT. Maybe some of them could make sense in a more general case (or just in all IDEs) and could be worth going upstream, but we're not pushing hard for that at the moment, because we are not so convinced yet that those bits of code would be better placed in openjdk code than in this repo.