Support an alternative compiler (e.g., Javac) to build projects and generate class files

[testforstephen]

From time to time, we observe discrepancies in compiler implementation between ECJ and Javac, particularly in areas such as generic type inference and annotation processing. Often, build tools like Maven or Gradle can compile the project successfully, but ECJ fails, causing compilation errors that block the run/debug behavior in the IDE.

To address this, we're experimenting with allowing the JDT to support an alternative compiler for building Java projects and generating class files. This new compiler would be used by JavaBuilder for project compilation only and would not impact basic language features like code completion and navigation, which would continue to use ECJ for the type system. We believe that offering an alternative compiler will benefit both the IDE and developers, allowing them to choose the compiler that best suits their needs.

To integrate a new compiler in JavaBuilder, we need to make minor refactorings to the AbstractImageBuilder, specifically to open up the API for initializing a different compiler. The implementation of the new compiler itself can be handled in a separate plugin.

We are opening this ticket to initiate the discussion. In the meantime, we will prepare a draft pull request to discuss the API design required to support a new compiler in JavaBuilder.

[jukzi]

jdt is not only used to generate .class files but also for things like codecompletion, refactorings etc. it is an alternative to javac. No one can stop you from building a distinct builder, but you better don't expect any help from jdt team which has enough todo to keep ecj as java alternative alife.
i think It would be even more frustrating for a user when the UI parses the java code different then the compiler. so it's better a replace both parsers or none.

see also https://github.com/eclipse-jdt/eclipse.jdt.core/pull/1984#issuecomment-2082236821

[mickaelistria]

No one can stop you from building a distinct builder

Indeed, and it's already done in a fork.

you better don't expect any help from jdt team which has enough todo to keep ecj as java alternative alife.

To be clear, the work is already done, and no-one is asking help nor anyone else to put extra manpower here as most of the work is already done in a fork. We're more willing to evaluate whether JDT committers are open to the idea of 1. allowing to host some code to plug-in an alternative AbstractImageBuilder and 2. maybe host of javac-based implementation for it; so we can limit how our fork diverges from JDT and contribute in making JDT more powerful in the end.

I understand that current contributors can be busy, but we're not trying to make them any busier (beyond just saying "yes, we can welcome code that allows to use an alternative AbstractImageBuilder"); so this argument doesn't really stand here. We're more curious about technical arguments why such a contribution allowing to choose a compiler could be harmful to the project.

[jukzi]

There is technical no need to make any change in jdt, just define your own "javac" nature with its own builder and leave the jdt.core.javanature as is.

[mickaelistria]

There is technical no need to make any change in jdt

Yes, there is a need for it as the JavaBuilder does evaluate what files to builds according to build order, modified resources and so on. We don't want to duplicate that important bit of smartness, we just want to reusing and be able to hook in an alternative code generation while still reusing most JDT smartness.

[iloveeclipse]

I personally think having a handy option to switch to alternative compiler implementation would be interesting (for example to investigate compiler differences). The question is only how much of code is needed and if that new code would cleanly integrate with existing one.

So if you made already some progress and have something to show, please create draft PR to discuss.

[stephan-herrmann]

I personally think having a handy option to switch to alternative compiler implementation would be interesting (for example to investigate compiler differences).

FYI: Once problematic code has been isolated to a test case the option to run ecj and javac back-to-back is already baked into our test infrastructure (AbstractRegressionTest). I've started to rely more on that for BETA_JAVA23 development.

[mickaelistria]

I think we can close it (I cannot do it as I'm not a committer), since #2497 is merged and we have a demo showing it works as expected. Further issues/ideas would better be tracked in new issues.