Not a class error for generated constructor in nested class when using ECJ (and lombok)
#268
Comments
|
One more note: This is with ECJ |
|
Type annotations are tricky, so thanks for providing a reproducer. I should have time to look at it next week. |
|
So here's a minimal reproducer: <?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>jandex-repro</artifactId>
<version>1.0.0-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<maven.compiler.release>17</maven.compiler.release>
<version.jandex>3.0.1</version.jandex>
<version.maven-compiler-plugin>3.10.1</version.maven-compiler-plugin>
<version.plexus-compiler>2.12.1</version.plexus-compiler>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${version.maven-compiler-plugin}</version>
<configuration>
<compilerId>eclipse</compilerId>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-api</artifactId>
<version>${version.plexus-compiler}</version>
</dependency>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-eclipse</artifactId>
<version>${version.plexus-compiler}</version>
</dependency>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-manager</artifactId>
<version>${version.plexus-compiler}</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>io.smallrye</groupId>
<artifactId>jandex-maven-plugin</artifactId>
<version>${version.jandex}</version>
<executions>
<execution>
<id>make-index</id>
<goals>
<goal>jandex</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>package com.example;
@interface MyAnnotation {
}
public class TopLevelClass {
private class InnerClass {
@MyAnnotation
public InnerClass() {
}
}
}I added a little bit of debugging info and the exception indeed points to the Interesting observation: if I comment out The reproducer is so simple I'd very much expect existing tests to catch the problem. There are CI runs with ECJ, except they seem to target very old Java bytecode. Changing |
|
Actually here's the truly minimal reproducer: @Target(ElementType.TYPE_USE)
@interface MyAnnotation {
}
public class TopLevelClass {
private class InnerClass {
@MyAnnotation
public InnerClass() {
}
}
}This causes indexing failure even with stock javac. The reason why the original reproducer only fails with ECJ is that ECJ is buggy -- it treats a non-type annotation as a type annotation. If the annotation is explicitly made a type annotation, the indexing problem persists -- and that is because the type annotation is present on type |
|
Okay, so I can see some possible fixes:
I guess I'd prefer 2, then 3, then 1 (even though 1 is conceptually nicest). @n1hility any opinions here? :-) |
|
Oh wow, so I "found" a real gem here. 😉 |
|
Indeed you did :-) Fortunately, the really tricky methods all work fine once supplied with a synthetic |
|
I'm looking at the details again and a type annotation may have a non-empty path in 3 cases:
In case of constructors, the type of the constructor is always the type of the declaring class, so cases 1 and 2 do not apply. Further, even if the declaring class is nested, the outer components of the class name cannot be denoted [in the constructor name], so case 3 always collapses to a type annotation on the inner-most type. So option 2 above actually doesn't lose any information and we can safely put the type annotations on the Will submit a PR shortly. |
|
Done. I will release 3.0.2 tomorrow, unless something proves horribly broken. |
|
@Ladicek cool, thanks! I suppose Quarkus also needs this update, not just the Maven plugin? |
|
I believe if you index the JAR with Jandex 3.0.2 (once I'm able to release it...), you should be able to use it with Quarkus 2.14. But I'll update Quarkus to Jandex 3.0.2 anyway, and probably even propose a backport to 2.14.x. |
|
Yeah, success finally! :-) Jandex 3.0.2 is in Central now. |
See this reproducer: code-with-quarkus.zip
Run
./mvnw -e clean package(looking at the code involved, it's a bit funny that
Indexerwas about to throw an exception anyway)I debugged a bit and it seems it stumbles upon the constructor of
AfterCommittedSynchronization(see@RequiredArgsConstructor).The generated constructor receives
@SuppressFBWarnings(justification = "generated code")via lombok.Context
I'm running the "old" jboss jandex plugin 1.2.3 just fine in a Quarkus 2.13.3.Final project.
Now that Quarkus 2.14.0.Final is available and is using Jandex 3.0.1, it was time to me to switch to the new coordinates and update.
That's when I ran into this issue. This
AsyncEventSenderis 1:1 from my actual project.I wasn't able to reproduce this error with vanilla compiler setup, I had to use ECJ (eclipse compiler) instead!
I guess lombok is not even required to provoke this error, but I wanted to keep closer to my real-world setup.
If required, I can try to kick lombok out of the reproducer.
The text was updated successfully, but these errors were encountered: