CODEWITHSUNDEEP
javaeclipseecj
Gelin Luo
Gelin Luo

Reputation: 14373

Is the standalone ecj (Eclipse Java Compiler) package no longer maintained?

We are using ecj from org.eclipse.jdt.core.compiler in our project, however it looks like the package is not updated since 07-Oct-2016. Is it no longer maintained?

enter image description here

Or should I switch to the ecj from org.eclipse.jdt? Looks like the version number (3.20.0) is older than the former: 4.6.1?

Upvotes: 4

Views: 1746

Answers (2)

VonC
VonC

Reputation: 1327784

That will change with Eclipse 4.27 (2023-03 release):

ECJ separated from JDT Core

Historically the code for ECJ was always in the same org.eclipse.jdt.core project that also contained the code for the Java support in the IDE, just in a different source folder.

The well known standalone ECJ compiler library that could be used outside of Eclipse (for compilation with external tooling) was generated out of this core bundle at build time and was not included in the default SDK (because it contained subset of packages and classes provided by org.eclipse.jdt.core).

This lead to few issues, with both Eclipse / standalone use of the ECJ compiler.

  • The (non-JDT) code inside Eclipse that required "default" javax.tools.JavaCompiler API implementation and had no need for full JDT / workspace support was not able to use org.eclipse.jdt.core without pulling in org.eclipse.core.resources bundle and so the dependency to the workspace.
  • Another interesting side effect of hosting ECJ code next to IDE code inside same org.eclipse.jdt.core bundle was that developers couldn't see if the ECJ code per mistake got some dependency to the IDE.

To resolve these (and other) problems, the ECJ code is moved from org.eclipse.jdt.core to dedicated org.eclipse.jdt.core.compiler.batch project and will be deployed as a separated bundle.

The org.eclipse.jdt.core.compiler.batch is now included in SDK as a regular Eclipse bundle and can be compiled / deployed / used separately from org.eclipse.jdt.core bundle.

All of ECJ packages are re-exported by org.eclipse.jdt.core, therefore from OSGI point of view, all 3rd party code that used some compiler related API from org.eclipse.jdt.core doesn't require any change.
The org.eclipse.jdt.core.compiler.batch bundle itself doesn't have any dependencies and so can be used in Eclipse products that do not use workspace concepts.

However, no change is without side effects.

Known problems with the split of the ECJ from core bundle

  • As part of the org.eclipse.jdt.core.compiler.batch code separation from org.eclipse.jdt.core, the two fragments of org.eclipse.jdt.core - org.eclipse.jdt.compiler.apt and org.eclipse.jdt.compiler.tool were merged into org.eclipse.jdt.core.compiler.batch.
    So if some target definition, launch configuration or build file referenced the two fragments, these references can and should be removed now.

  • Another issue might affect standalone (non OSGI based) applications that were using org.eclipse.jdt.core as a "simple" Java library (which jdt.core never was).
    So for example code that had org.eclipse.jdt.core_XYZ.jar on classpath and tried to call this outside Eclipse:

    ASTParser parser = ASTParser.newParser(AST.getJLSLatest());

    would fail now with:

    NoClassDefFoundError: org.eclipse.jdt.internal.compiler.env.ICompilationUnit

    because org.eclipse.jdt.core.dom.ASTParser uses internally ECJ APIs and they are now ... surprise ... moved to org.eclipse.jdt.core.compiler.batch jar.
    To fix this error, org.eclipse.jdt.core.compiler.batch library should be added to the application classpath.

Upvotes: 1

Stephan Herrmann
Stephan Herrmann

Reputation: 8178

The official coordinates of ecj in Maven are indeed: org.eclipse.jdt:ecj.

As you can see, this artifact exists in all release versions since 3.12.3 (corresponding to Neon.3).

Artifacts in other groups may have mistakenly used the version number of the Eclipse release, not that of ecj itself, thus appearing to be newer even if they are (a lot) older.

(When Eclipse SDK was bumped up from 3.x to 4.x this was due to breaking changes in the UI part of the code. ecj, however, remained compatible and thus stayed at 3.x)

In case of doubt, run the following to see the real version of ecj:

$ java -jar ecj.jar -version

The latest release version will answer

Eclipse Compiler for Java(TM) v20191203-2131, 3.20.0, Copyright IBM Corp 2000, 2015. All rights reserved.

Upvotes: 3

Related Questions