Comment 1 Jay Arthanareeswaran 2019-08-14 01:00:57 EDT

The exception is intentionally thrown with the following comment:

// catch the case that a type inside a source file has been renamed but other class files are looking for it

Michael, I don't know what the annotation processor is trying to do. Is it trying to do what the comment says?

Comment 2 Michael Seele 2019-08-14 01:17:40 EDT

(In reply to Jay Arthanareeswaran from comment #1)
> The exception is intentionally thrown with the following comment:
> 
> // catch the case that a type inside a source file has been renamed but
> other class files are looking for it
> 
> Michael, I don't know what the annotation processor is trying to do. Is it
> trying to do what the comment says?

I don't think so, it even fails when you do a complete rebuild. It just don't work in eclipse.

It's the annotation processor from the Google Auto Value Project: https://github.com/google/auto/tree/master/value
The guys hat Google are saying its a bug in the eclipse compiler. 
Please see https://github.com/google/auto/issues/738

You can easily create a example project with the snippet above. Does it help when i attach a sample eclipse project?

Comment 3 Jay Arthanareeswaran 2019-08-14 01:58:56 EDT

(In reply to Michael Seele from comment #2)
> You can easily create a example project with the snippet above. Does it help
> when i attach a sample eclipse project?

That would certainly speed up things. TIA!

Comment 4 Michael Seele 2019-08-14 02:13:09 EDT

Created attachment 279564 [details]
example project

This seems to work as a single file project. But when i copy the class into an existing project with a few 100 classes, it fails with the posted error.

Maybe it has something to do with the incremental build. But the incremental build should work for that anyway.

Comment 5 Jay Arthanareeswaran 2019-08-28 00:28:34 EDT

(In reply to Michael Seele from comment #4)
> Created attachment 279564 [details]
> example project
> 
> This seems to work as a single file project. But when i copy the class into
> an existing project with a few 100 classes, it fails with the posted error.
> 
> Maybe it has something to do with the incremental build. But the incremental
> build should work for that anyway.

Can you tell me what I need to do? Should I set up a project with lot of classes with the auto value annotations JAR and then copy the Outer into that project?

Comment 6 Michael Seele 2019-08-28 01:35:49 EDT

(In reply to Jay Arthanareeswaran from comment #5)
> (In reply to Michael Seele from comment #4)
> > Created attachment 279564 [details]
> > example project
> > 
> > This seems to work as a single file project. But when i copy the class into
> > an existing project with a few 100 classes, it fails with the posted error.
> > 
> > Maybe it has something to do with the incremental build. But the incremental
> > build should work for that anyway.
> 
> Can you tell me what I need to do? Should I set up a project with lot of
> classes with the auto value annotations JAR and then copy the Outer into
> that project?

Maybe take a look at the following code. With auto-value release 1.6.6 i don't get this bug anymore because the guys at google added a workaround for the eclipse behaviour/bug:

https://github.com/google/auto/blob/master/value/src/main/java/com/google/auto/value/processor/EclipseHack.java

https://github.com/google/auto/commit/42592610072358c2e1aed83049919677e30cda35#diff-b86b5a01c93b89a20e3888f75497a3f0

Comment 7 Stefan Ocke 2019-10-05 13:00:56 EDT

I get the same exception with my annotation processor as soon as Java > 8.
I can can confirm that I do "something with inner classes" as well.

The error is only within Eclipse. 

It does not appear in a clean Maven build with ejc (3.19). See also https://travis-ci.org/japkit/japkit-examples/builds/593973870

In Eclipse it happens even with clean build.

I will try to provide more details asap.

Comment 8 Stefan Ocke 2019-10-06 03:48:06 EDT

Sorry, my exception is different. I will create a new bug.

org.eclipse.jdt.internal.compiler.problem.AbortCompilation: , cause:  
		org.eclipse.jdt.internal.core.builder.NameEnvironment.findClass(NameEnvironment.java:476)
				org.eclipse.jdt.internal.core.builder.NameEnvironment.findType(NameEnvironment.java:546)
				org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.lambda$0(LookupEnvironment.java:237)
				org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForTypeFromModules(LookupEnvironment.java:372)
				org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:236)
				org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getType(LookupEnvironment.java:1701)
				org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getType(LookupEnvironment.java:1670)
				org.eclipse.jdt.internal.compiler.apt.model.ElementsImpl9.getTypeElement(ElementsImpl9.java:81)
				org.eclipse.jdt.internal.compiler.apt.model.ElementsImpl9.getTypeElement(ElementsImpl9.java:53)

Comment 9 Stefan Ocke 2019-10-06 03:50:11 EDT

No. It IS the same. Sorry again.

Comment 10 Stefan Ocke 2019-10-06 04:19:51 EDT

More details:

- For me, it happens "always". Even with a small amount of classes.
- It happens exactly when Elements.getTypeElement() is called for an inner class that does not exist (yet).
- According to the spec, null should be returned in this case, but never an exception.
- I worked around it by catching the exception and returning null by myself, but, Jay, this should not be the long term solution...

Comment 11 Stefan Ocke 2019-10-06 04:57:30 EDT

P.S.: In the EclipseHack mentioned above, the workaround seems to be for a different kind of issue with inner classes. So, my case might be an additional one to consider when fixing it...

Comment 12 Stefan Ocke 2019-10-06 07:28:34 EDT

It is even worse than expected at first an my workaround is not sufficient:

- During clean build, the exception occurs for NON-EXISTING inner classes (as mentioned before).

- But during incremental buid, the exception even occurs for EXISTING inner classes.

For whatever reason this Exception has been added in NameEnvironment... Please make it disappear again in annotation processing...

Comment 13 Stefan Ocke 2019-10-06 10:27:04 EDT

I did some more debugging and I think I understand it better now:

As mentioned earlier, the exception is thrown here:

private NameEnvironmentAnswer findClass(String qualifiedTypeName, char[] typeName, LookupStrategy strategy, String moduleName) {
	...

	String moduleQualifiedName = moduleName != null ? moduleName+':'+qualifiedTypeName : qualifiedTypeName;
	if (this.initialTypeNames != null && this.initialTypeNames.includes(moduleQualifiedName)) {
		if (this.isIncrementalBuild)
			// catch the case that a type inside a source file has been renamed but other class files are looking for it
			throw new AbortCompilation(true, new AbortIncrementalBuildException(qualifiedTypeName));


My first assumption was, that the Exception is thrown here for the inner class. 
But this ist NOT the case. 
When calling findTypeElement for an InnerClass, then findClass for the outer class is called.

In both of my error cases, that outer class was in the "initialTypeNames". I guess they match more or less with the root elements of the current round of annotation processing.

So that means, it is not possible anymore to call findTypeElement for any root element or some of its inner classes.

While it might seem unnecessary to call findTypeElement on those classes (since we have them already in RoundEnvironment), it is not forbidden in the annotation processing API and Eclipse should also not forbid it.

Comment 14 Scott Cameron 2020-12-05 04:47:58 EST

Is it possible that this issue is related to this? 
https://www.eclipse.org/forums/index.php?t=msg&th=1106152&goto=1835494&#msg_1835494

I recently observed some special behavior in getTypeElement when compiling with JDT, only with JDK 9 or greater. JDK 1.8 works fine as does the compiler under Maven with any JDK version. Qualified nested class names with a ‘.’ separator hit the exception shown above, but using the same name with ‘$’ as the separator before the nested class name works in JDT (but not anywhere else).

So this hits your exception:

elements.getTypeElement("com.scott.MyClass.MyNestedClass");

But this works fine:

elements.getTypeElement("com.scott.MyClass$MyNestedClass");

Since JDT under JDK 1.8 seems to accept both, a workaround that seems to work for me is to just detect if I’m running in Eclipse and use ‘$’ in that case, but ‘.’ in all other cases. Then both my Eclipse build and Maven build seem to work with any JDK version I’ve tried so far. 

Is it possible this is the same issue?

Comment 15 Tom Vandenbussche 2020-12-23 07:02:12 EST

Having similar issues after switching to Java 11. This is the stacktrace I get:

@AutoValue processor threw an exception: org.eclipse.jdt.internal.compiler.problem.AbortCompilation: 
	at org.eclipse.jdt.internal.core.builder.NameEnvironment.findClass(NameEnvironment.java:476)
	at org.eclipse.jdt.internal.core.builder.NameEnvironment.findType(NameEnvironment.java:546)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.lambda$0(LookupEnvironment.java:237)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForTypeFromModules(LookupEnvironment.java:372)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:236)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getType(LookupEnvironment.java:1732)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getType(LookupEnvironment.java:1701)
	at org.eclipse.jdt.internal.compiler.apt.model.ElementsImpl9.getTypeElement(ElementsImpl9.java:81)
	at org.eclipse.jdt.internal.compiler.apt.model.ElementsImpl9.getTypeElement(ElementsImpl9.java:53)
	at com.google.auto.value.processor.TypeEncoder$TypeRewriter.classForName(TypeEncoder.java:461)
	at com.google.auto.value.processor.TypeEncoder$TypeRewriter.findReferencedClasses(TypeEncoder.java:454)
	at com.google.auto.value.processor.TypeEncoder$TypeRewriter.rewrite(TypeEncoder.java:416)
	at com.google.auto.value.processor.TypeEncoder.decode(TypeEncoder.java:139)
	at com.google.auto.value.processor.TypeEncoder.decode(TypeEncoder.java:132)
	at com.google.auto.value.processor.AutoValueProcessor.processType(AutoValueProcessor.java:266)
	at com.google.auto.value.processor.AutoValueOrOneOfProcessor.process(AutoValueOrOneOfProcessor.java:312)
	at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:142)
	at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:124)
	at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:171)
	at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:138)
	at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:950)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:450)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:426)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:386)
	at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:371)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:318)
	at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.incrementalBuildLoop(IncrementalImageBuilder.java:190)
	at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:147)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:292)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:212)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:845)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:228)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:276)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:329)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:332)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:384)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:405)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:154)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:244)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Comment 16 Tom Vandenbussche 2020-12-23 07:32:12 EST

This is the code that triggers the exception mentioned in the previous comment:

@AutoValue
public abstract class Data<T> {
	@AutoValue
	public abstract static class Nested<T> {
		public abstract T data();
	}

	@AutoValue.Builder
	public abstract static class Builder<T> {
		public abstract Builder<T> nested(Nested<T> nested);
		public abstract Data<T> build();
	}

	public abstract Nested<T> nested();
}

Comment 17 Mark Christiaens 2021-06-14 04:15:36 EDT

I'm also seeing the same issue with Eclipse 2021-03

Comment 18 Eclipse Genie 2024-04-23 12:28:26 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.