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

Bug 522244

Summary: Specific context where classes are generated by APT, but not compiled
Product: [Eclipse Project] JDT Reporter: Cristian <cristian.spiescu>
Component: APTAssignee: Generic inbox for the JDT-APT component <jdt-apt-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: critical    
Priority: P3 CC: jarthana
Version: 4.7   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard: stalebug

Description Cristian CLA 2017-09-13 10:10:09 EDT
I continue here the discussion that I have started on the forum at: https://www.eclipse.org/forums/index.php/t/1088737/

After investigations, here as my findings:

1) How to reproduce:

I have

@GenAnnot1
@GenAnnot2
class MyClass {}

I.e. 2 annotations that have processors associated.

* GenAnnot1 processor generates GeneratedClass1. 
* GenAnnot2 processor generates GeneratedClass2 extends SomeAncestor<GeneratedClass1>.

RESULT: the 2 classes are generated as source files. But they are not compiled. I.e. their corresponding .class doesn't exist.

2) Findings in code:

The issue reproduces both after a clean+compile or when working incrementally. So, I modify MyClass. The processors are invoked correctly. Then Compiler.addCompilationUnit() is invoked for GeneratedClass1, GeneratedClass2, and stored in Compiler.unitsToProcess. Other generated classes are also passed to Compiler.addCompilationUnit().

Then we are in Compiler.compile(). We have just caught an exception: SourceTypeCollisionException, so we enter "backupAptProblems()". This method iterates over all elements in "unitsToProcess". I.e. GeneratedClass1, GeneratedClass2 and some other classes. Only one class among them has problems: GeneratedClass2: "Pb(327) The hierarchy of the type MyEntityService is inconsistent". 

No class among them is saved for later. Neither the one with no issues, nor GeneratedClass2, because I see that only problems of type CategorizedProblem.CAT_UNSPECIFIED are taken into account.

The result is that ALL the classes in "unitsToProcess" are now discarded. And compilation won't be reattempted for them. My understanding of the code tells me that "backupAptProblems()" should have saved them for later. Is my understanding wrong? Is there another mechanism by which these classes would be compiled? If no => this is the issue.
Comment 1 Cristian CLA 2017-09-13 11:21:28 EDT
The workaround I have implemented is the following: for each processor, I remember the source files that I have created. At the end, i.e. during the final round, I find their real location on the disk and I "touch" them. This way, Eclipse recompiles them.

I cannot say that I am mad about this solution, but it works.

What's nasty about the issue, is that among several generated files, some of them simple some of them complex: if a complex file generated the issue, it penalizes also simple files that have been generated meanwhile.
Comment 2 Jay Arthanareeswaran CLA 2017-09-14 02:30:55 EDT
(In reply to Cristian from comment #0)
> No class among them is saved for later. Neither the one with no issues, nor
> GeneratedClass2, because I see that only problems of type
> CategorizedProblem.CAT_UNSPECIFIED are taken into account.
> 
> The result is that ALL the classes in "unitsToProcess" are now discarded.
> And compilation won't be reattempted for them. My understanding of the code
> tells me that "backupAptProblems()" should have saved them for later. Is my
> understanding wrong? Is there another mechanism by which these classes would
> be compiled? If no => this is the issue.

I haven't had a close look at it, as the team is busy with Java 9 work. But I think the code you are looking at is a possible suspect. If you can find some time, please propose a fix, I will be happy to review and take it forward.
Comment 3 Eclipse Genie CLA 2019-10-10 13:35:14 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.