Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 495225

Summary:	APT does not generate import statements for other generated types
Product:	[Eclipse Project] JDT	Reporter:	Michael Bolin <bolinfest>
Component:	APT	Assignee:	Generic inbox for the JDT-APT component <jdt-apt-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	e.lucash, jarthana
Version:	4.6
Target Milestone:	---
Hardware:	Macintosh
OS:	Mac OS X
Whiteboard:	stalebug

Description Michael Bolin

2016-06-01 18:31:55 EDT

[Buck](https://github.com/facebook/buck) uses the [Immutables annotation processor](http://immutables.github.io/) to generate many types. I know that a bunch of work has been done recently to fix issues with Eclipse's APT and Immutables, but it isn't quite there yet.

As I noted in [this recent commit](https://github.com/facebook/buck/commit/fc3b37f69ea0acbcf6f256462950bd3ed2bf459b), when I load the Buck project in Eclipse 4.6.0RC2 and choose "Project > Clean..." and select Buck, I still get a broken build due to compilation errors in files in the generated .apt_generated folder.

Alphabetically, the first such error is in .apt_generated/com/facebook/buck/android/AndroidPackageableCollection.java. It complains about two unknown types: BuildTarget and BuildConfigFields. However, these files exist (Eclipse even takes you to them if you cmd-click on their names in AndroidPackageableCollection.java):

.apt_generated/com/facebook/buck/model/BuildTarget.java
.apt_generated/com/facebook/buck/rules/coercer/BuildConfigFields.java

The issue is that there are no import statements for these types in AndroidPackageableCollection.java.

Note that this is not an issue when these files are generated via the annotation processing logic that comes with javac when run from the command line. The missing import statements are the only difference between the javac and ECJ versions; otherwise, they are byte-for-byte identical.

Comment 1 Ievgen Lukash

2016-06-01 19:36:35 EDT

Thank you Michael for reporting this! It's probably to early to declare any specific problem with ECJ. Let me investigate it on the side of Immutables, I'll get back here to report findings.

Comment 2 Ievgen Lukash

2016-06-05 23:24:23 EDT

The problem was in the change in annotation processor classloading in Eclipse.
When running in IDE (as opposed to running compiler in a batch mode), Thread.getContextClassLoader() able to provide a classloader that load ECJ-specific classes throught which we access necessary advanced functionality.

I believe the changes in classloading was necessary for something important, so we adapted the Immutables annotation processor to use special proxy classloader to work around the change.

I would say that this would never be an issue if the annotation processor use only standard apis and never touch compiler internals, but the amount of bugs in both Javac and ECJ, and other discrepancies between the two are too much of a problem and it cannot be dealt with only using standard APIs.

Comment 3 Eclipse Genie

2018-09-29 12:18:08 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.

Comment 4 Ievgen Lukash

2018-10-01 12:26:24 EDT

Not an issue. At some point, classloading was changed when running ECJ APT in IDE, but the library mentioned Immutables.org was adapted to this change and the issue was resolved.