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

Bug 500589

Summary: TypeElement.getEnclosedElements does not reflect declaration order when sourced from a compiled class
Product: [Eclipse Project] JDT Reporter: Christian Manning <christianm>
Component: APTAssignee: Generic inbox for the JDT-APT component <jdt-apt-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: eamonn, eclipse, octavia.togami, stefan.eggerstorfer
Version: 4.6   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=300408
https://git.eclipse.org/r/80142
https://git.eclipse.org/r/97595
Whiteboard: stalebug
Attachments:
Description Flags
Reproducing project none

Description Christian Manning CLA 2016-08-31 10:30:17 EDT 
Created attachment 263869 [details]
Reproducing project

TypeElement.getEnclosedElements() should be returning elements in the order they were declared. This was previously reported in bug #300408, but only for TypeElements coming from source files. This bug is for TypeElements representing already compiled types.

Attached is a project that will demonstrate the difference in output between JDT and javac. This uses a simple annotation processor & invokes the JavaCompilers directly in a unit test (ElementOrderProcessorTest). There's a jar in there with a couple of simple POJOs, as this behaviour is only revealed when the TypeElement comes from a compiled class.

I have a fix for TypeElementImpl, I'm just looking into the process for contribution.


Reproducible: Always

Steps to Reproduce:
1. Create an annotation processor that calls getEnclosedElements() on a TypeElement for a type originating from byte code.
2. Create a class with an annotation that will trigger the created annotation processor.
3. Analyse the order of elements returned by TypeElement.getEnclosedElements().
Comment 1 Eclipse Genie CLA 2016-08-31 11:59:15 EDT 
New Gerrit change created: https://git.eclipse.org/r/80142
Comment 2 Stefan Eggerstorfer CLA 2016-12-20 01:42:46 EST 
I have the same issue with AutoValue (relys on the method order) failing in Eclipse but succeeding with javac. My class using the AutoValue annotation is a source file, but it implements an interface coming from a referenced library.

About the patch: I compared it with SourceLocationComparator, and I guess there are still some cases missing. It is only handling VariableElementImpl, but ignoring TypeElementImpl and ExecutableElementImpl, see SourceLocationComparator.determineSourceStart(ElementImpl).
Comment 3 Christian Manning CLA 2016-12-20 18:01:29 EST 
Yes, unfortunately my patch wouldn't work in all cases, only fields. It relies on the fact that FieldBinding is for all kinds of fields, including static, and therefore enum values. Enum values are ordered so FieldBinding has an ordinal. This was enough for our needs using Dagger (not that I'm running a patched eclipse for daily dev mind you ;)). Generally we just have to remember to order our fields alphabetically by name for certain classes or the eclipse users in our team get errors.

Perhaps the other Binding types can get an ordinal too, which is always representative of the order of declaration. The spec states that it should be the "natural order". Is the order in the class files consistent with the order of declaration in the source? Either way, this kind of code compiles successfully with javac but does not in eclipse.
Comment 4 Walter Harley CLA 2016-12-22 02:30:46 EST 
Typically I think the Sun/Oracle folks have intended "natural order" to mean "source file order", for types coming from source files.

For types coming from jar files it is harder to say.
Comment 5 Kenzie Togami CLA 2017-05-22 13:22:35 EDT 
I have a slightly better version of the patch linked here, https://git.eclipse.org/r/#/c/97595/, but I'm not sure it's the best solution. I'd love for this to be fixed ASAP, as this is severely hindering development for me.
Comment 6 Eclipse Genie CLA 2020-03-21 13:17:53 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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.