Eclipse Neon (4.6.2) + Oxygen (4.7) producing wrong orders of methods #383
Comments
|
Here's an example test case: https://gist.github.com/kenzierocks/a9ec27a66b9a71d6e02513c902d2091f |
|
Thanks for the report! It's surprising, because the Eclipse method-sorting bug was supposed to have been fixed in 4.5. I wonder if EclipseHack is proving counterproductive here. It's still doing reordering of methods on Eclipse, even though they are supposed to be in the right order already. The assumption is that at worst EclipseHack will derive the same order of methods from the parsing that it does. But maybe that's not true on Oxygen for some reason. If there is a clean(ish) way to discover what the Eclipse version is from within an annotation processor, I could turn off the method-ordering workaround for version ≥ 4.5. Or, we could just assume that everyone is on at least 4.5 by now and remove the workaround. |
|
I think what we should probably do is remove the method-ordering logic from AutoValue after 1.4 is released (which should be soon). Then people who are stuck on ancient Eclipse versions will just have to stick to AutoValue 1.4. |
|
Is there an ETA for AutoValue 1.4? It looks like the latest version of Eclipse (Neon.2) includes a similar fix as old Oxygen builds did, so right now it's almost impossible to work efficiently with AutoValue classes in a project. If it will still be a while until a fix drops, maybe consider adding a |
octylFractal
changed the title
|
I think we should be releasing 1.4 Real Soon Now. I have one change in flight and then I am keen on getting 1.4 out. Apart from getting rid of the method-ordering hack, the plan is to start requiring a Java 8+ compiler after 1.4. (We'll still support handling Java 6 code, but the compiler itself must be at least Java 8.) |
|
[EDIT] [EDIT2] |
…. The bug was fixed in Eclipse 4.5, which was released in June 2015. Users who need to use AutoValue with earlier versions of Eclipse will have to stay on AutoValue 1.4. Fixes #383 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=152273001
|
I plan to cut a 1.4.1 release very soon that will remove the method-ordering logic as I described above. At that point, if anyone still encounters this problem we will need to reopen this issue. |
|
1.4.1 has now been released. |
|
I thought this was fixed, but for some reason Eclipse 4.6.3 just started kicking this off again. I'm using AutoValue 1.4.1, so I'm baffled as to what could be causing this. I'm investigating it locally. |
|
It looks like it is solved by updating to Oxygen M7. Perhaps there is a bug in Neon that got fixed. Edit: It looks like M7 only reverted it to what it was before, "It only occurs when Eclipse does a recompile while I edit, it is fine when I do Clean Project." Neon seemed to have the bug no matter what I did. |
|
It seems the original eclipse bug only fixed compiling from source, which is why I only see it when I edit the affected files. I've left a comment on the original bug, and will be handling patching it with them. This issue can remain closed. |
|
Thanks for the update! Yes, I think trying to work around these Eclipse bugs in AutoValue was already a losing battle and we probably won't try to imitate the workaround mentioned here. |
It looks like the Eclipse hack may have broken in 4.7, as I'm getting alphabetical orderings of methods again. It only occurs when Eclipse does a recompile while I edit, it is fine when I do
Clean Project. I don't think this is very high priority since Oxygen isn't out yet, but I wanted to give you notice.The text was updated successfully, but these errors were encountered: