ECJ usage broken in 2.14.x

[kriegaex]

Create a new project (no sources needed) with this POM:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.acme</groupId>
  <artifactId>example</artifactId>
  <version>0.0.1-SNAPSHOT</version>

  <properties>
    <!-- 2.13.0 works, 2.14.x yields error "No such compiler 'eclipse'" -->
    <plexus-compiler.version>2.14.2</plexus-compiler.version>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.12.1</version>
        <configuration>
          <compilerId>eclipse</compilerId>
          <source>11</source>
          <target>11</target>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.codehaus.plexus</groupId>
            <artifactId>plexus-compiler-eclipse</artifactId>
            <version>${plexus-compiler.version}</version>
          </dependency>
        </dependencies>
      </plugin>
    </plugins>
  </build>

</project>

Running mvn compile -e yields:

[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] 
[INFO] --------------------------< org.acme:example >--------------------------
[INFO] Building example 0.0.1-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- resources:3.3.1:resources (default-resources) @ example ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Users\alexa\Documents\java-src\JDTCore-gh-1676\_x\src\main\resources
[INFO] 
[INFO] --- compiler:3.12.1:compile (default-compile) @ example ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.348 s
[INFO] Finished at: 2023-12-29T09:55:07+07:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.12.1:compile (default-compile) on project example: No such compiler 'eclipse'. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.12.1:compile (default-compile) on project example: No such compiler 'eclipse'.
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:333)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
    at java.lang.reflect.Method.invoke (Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)
Caused by: org.apache.maven.plugin.MojoExecutionException: No such compiler 'eclipse'.
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:683)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:212)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
    at java.lang.reflect.Method.invoke (Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)
[ERROR] 
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

The result is the same on 2.14.0, 2.14.1, 2.14.2. With 2.13.0, it works.

[slawekjaranowski]

What version of Maven do you use?

Similar to #332

[kriegaex]

3.9.5. I quickly tried a few others for you: 3.9.4, 3.8.5, 3.6.3 - same result.

4.0.0-alpha-10 seems to work, at least in this empty project. Does that help you in any way? Have you tried to reproduce? It is really super simple, you only need the POM.

[slawekjaranowski]

You need at least 3.9.6 - https://issues.apache.org/jira/browse/MNG-7913

[pzygielo]

• No such compiler 'eclipse' when upgraded from 2.13.0 to 2.14.0 #332

[kriegaex]

Yes, it works on 3.9.6, thank you.

Hm, that error message is not so nice, as you can see from the duplicate issue here. If a minor library version upgrade forces a project to upgrade to the latest Maven release, I am expecting a more helpful error message, not just "No such compiler 'eclipse'". Could you please improve that? Imagine thousands of developers around the world getting Dependabot or Renovate suggestions to upgrade, and then there is this error message they do not understand, creating unnecessary work here like I did.

BTW, it is really unfortunate to change an important core library in a minor-minor Maven version, just because the old one does not support annotation scanning on JDK 17+, causing a breaking change for all plugins which need same annotation scanning. Of course, it is not Maven's fault that ECJ requires JDK 17+ now, also forcing its fork AJC to upgrade. So, I understand that in order to use ECJ or AspectJ with Plexus Compilers, JDK 17+ (as a build environment, not as a runtime environment for the compiled programs) is necessary, too. But that this forces users to upgrade to Maven 3.9.6 because of the breaking switch to Sisu, even though they previously had compiled their problems without any problems on Java 17 or 21 with Maven 3.9.5 or older, is really counter-intuitive. It would have been nice, if the old library could have been kept alive until a breaking change in Maven 4.

Anyway, sorry for straying off topic. A better error message is what I think justifies keeping this issue open.

[slachiewicz]

@kriegaex it is not breaking change in Maven. It's just a consequence of Eclise ECJ requiring Java 17.
In Maven we just added enhancement thanks to the upgrade of Eclise SIsiu to discover components compiled with Java 17.

Feel free to open PR with improvements to maven-compiler-plugin

[kriegaex]

it is not breaking change

Fine, then it simply has stopped working without a helpful error message.

I wonder why the default answer to users asking for something so often is "feel free to open a PR", instead of remembering to be a committer and improve something oneself. Am I really asking too much, hoping for a better, more informative error message?

[kriegaex]

@slachiewicz, @slawekjaranowski, can you please explain to me how DefaultCompilerManager.compilers is populated? I see that it is injected, but I do not understand how whatever scans this then decides which compilers to add to the map and which to skip. I would like to take a look at that, because IMO it was not a good decision to require Java 17 for ECJ, AJC and IT modules in Plexus Compiler. Look at how AspectJ.dev AspectJ Maven does it:

https://github.com/dev-aspectj/aspectj-maven-plugin/blob/c544e63fb017a6dae10d968c64d4d4acb505ec4e/pom.xml#L331-L342

The enforcer rule just skips aspectjtools and lets the errors occur on runtime, which is better, because then the user better understands what is wrong. The same could be done for ecj. Plus, it would enable users to downgrade ECJ and AJC to older versions in the plugin dependencies, if they decide to work with older compiler versions requiring only Java 11. Just because somebody upgrades Plexus, does not mean they need to be forced to upgrade Maven, AspectJ or ECJ.

[slachiewicz]

Eclipse Sisu does classpath scanning for classes annotated with @Named
If we have an older maven, Sisu cannot read classes compiled to Java 14+ and the map will not be populated.

[kriegaex]

This problem is not solved even in Maven 3.9.6. Just compile the same POM on a JDK older than 17. Even though Sisu-Inject 0.9.0.M2 contains ASM capable of parsing class files up to Java 21 and depends on Guice 5.1.0, which also contains its own relocated copy of ASM, but this time the highest class file version it knows is JDK 18. Both should be enough to parse (annotations on) Java 17 class files even when running the build on JDK 8, 11 or 16, then populate the compilers list and try to run e.g. Eclipse or AspectJ compilers, then probably failing due to unknown class file versions on the older JDK running the build, which would give users a clear indicator of what it wrong.

So, either there is yet another ASM somewhere in the belly of Maven or Maven Compiler, or maybe it is something else like CGLIB or whatever else it uses.

[kriegaex]

I was able to reproduce the problem locally with a mini Sisu project, compiling the class receiving the injection to target 8 and the @Named classes to be scanned to target 17. When running the program on JDK less than 17, simply nothing happens, no exception. Sisu simply catches the error. Only when running the JVM with -Dsisu.debug, I can finally see log output like this:

...
DEBUG: Sisu - Problem scanning: file:/C:/Users/alexa/Documents/java-src/plexus-compiler/_sisu/target/classes/example/RadioButtonTab.class
java.lang.TypeNotPresentException: Type example.RadioButtonTab not present
        at org.eclipse.sisu.space.URLClassSpace.loadClass(URLClassSpace.java:147)
        at org.eclipse.sisu.space.QualifiedTypeVisitor.leaveClass(QualifiedTypeVisitor.java:128)
        at org.eclipse.sisu.space.SpaceScanner$1.visitEnd(SpaceScanner.java:180)
        at org.eclipse.sisu.space.asm.ClassReader.accept(ClassReader.java:748)
        at org.eclipse.sisu.space.asm.ClassReader.accept(ClassReader.java:424)
...
Caused by: java.lang.UnsupportedClassVersionError: example/RadioButtonTab has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 60.0
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1010)
...
DEBUG: Sisu - Potential problem: example.Example
java.lang.UnsupportedClassVersionError: example/AbstractTab has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 60.0
...
TRACE: Sisu - Discard binding: UntargettedBinding{key=Key[type=example.Example, annotation=[none]], source=/C:/Users/alexa/Documents/java-src/plexus-compiler/_sisu/target/classes/}
TRACE: Sisu - Discard binding: LinkedKeyBinding{key=Key[type=java.lang.Object, annotation=*], source=/C:/Users/alexa/Documents/java-src/plexus-compiler/_sisu/target/classes/, scope=Scopes.NO_SCOPE, target=Key[type=example.Example, annotation=[none]]}

This is caused by the ASM class visitor here.

Just run the build for my POM on JDK less than 17 with Maven 3.9.6, and you will see what Sisu does:

MAVEN_OPTS=-Dsisu.debug mvn -V compile >build.log 2>&1

Then inspect the log:

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: C:\Program Files\Java\apache-maven-3.9.6
Java version: 11.0.10, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-11.0.10
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
TRACE: Sisu - Add publisher: com.google.inject.internal.InjectorImpl@69eb86b4

-----[explicit bindings]-------------------------------------------------------
...
[INFO] --- compiler:3.12.1:compile (default-compile) @ example ---
WARN: Sisu - Inconsistent ClassLoader for: interface com.google.inject.Module in: ClassRealm[plugin>org.apache.maven.plugins:maven-compiler-plugin:3.12.1, parent: jdk.internal.loader.ClassLoaders$AppClassLoader@2cdf8d8a]
WARN: Sisu - Expected: ClassRealm[plexus.core, parent: null] saw: ClassRealm[plugin>org.apache.maven.plugins:maven-compiler-plugin:3.12.1, parent: jdk.internal.loader.ClassLoaders$AppClassLoader@2cdf8d8a]
DEBUG: Sisu - Problem scanning: jar:file:/C:/Users/alexa/.m2/repository/org/codehaus/plexus/plexus-compiler-eclipse/2.14.2/plexus-compiler-eclipse-2.14.2.jar!/org/codehaus/plexus/compiler/eclipse/EclipseJavaCompiler.class
java.lang.TypeNotPresentException: Type org.codehaus.plexus.compiler.eclipse.EclipseJavaCompiler not present
	at org.eclipse.sisu.space.URLClassSpace.loadClass(URLClassSpace.java:147)
	at org.eclipse.sisu.space.QualifiedTypeVisitor.leaveClass(QualifiedTypeVisitor.java:128)
	at org.eclipse.sisu.plexus.PlexusTypeVisitor.leaveClass(PlexusTypeVisitor.java:117)
	at org.eclipse.sisu.space.SpaceScanner$1.visitEnd(SpaceScanner.java:180)
	at org.eclipse.sisu.space.asm.ClassReader.accept(ClassReader.java:748)
	at org.eclipse.sisu.space.asm.ClassReader.accept(ClassReader.java:424)
	at org.eclipse.sisu.space.SpaceScanner.accept(SpaceScanner.java:102)
	at org.eclipse.sisu.space.SpaceScanner.accept(SpaceScanner.java:78)
...
Caused by: java.lang.UnsupportedClassVersionError: org/codehaus/plexus/compiler/eclipse/EclipseJavaCompiler has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
...

So, the problem does not actually seem to be parsing the class with ASM and finding the annotations, but rather Sisu trying to load the class in URLClassSpace.loadClass. There is no option to throw an error, if a problem like that occurs, hence Maven or Maven Compiler also cannot catch any exceptions, trying to print a better error message. I have no deep insights in what Sisu does here, but if it simply tries to populate the list/map of compilers, it would not need to actually load them yet. Then later, when trying to run one of them, there would be a regular unsupported class version error, which the user could see.

Is there, to the best of your knowledge, any way to scan the annotations without actually loading the classes? I certainly know that ASM can do that, but it depends on how Sisu uses ASM.

[laeubi]

it is not breaking change in Maven. It's just a consequence of Eclise ECJ requiring Java 17.

This is only partly true, it is a consequence of using @Named... with @Component it works like a charm with older maven versions and that's the reason we didn't upgraded to the "better" @Named in Tycho yet .. and Maven was broken before. Another "fix" is to compile the component code with Java 11 bytecode (even though it makes not much sense if runtime requires java 17 anyways)

So even that @Component is "old school" it did a better job by defer the class scanning and problem diagnostic to the build-time rather than runtime.