-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eclipse can not resolve class dependency with classes that uses @Synchronized #290
Comments
👤 andreas.muenstermann@web.de 🕗 Jun 08, 2011 at 11:12 UTC What steps will reproduce the problem?
What version of the product are you using? On what operating system? Please provide any additional information below. |
👤 grootjans 🕗 Jun 08, 2011 at 18:16 UTC I was able to reproduce this both with the 0.9.3 and the edge release. A few important things to note;
|
👤 reinierz 🕗 Jun 13, 2011 at 20:37 UTC Well, this is some voodoo: If there are 10 annotations in a source file, this problem goes away. Generated annotations count, so just @ Data even with no fields is enough, as is @ ToString + @ EqualsAndHashCode (2 annotations right there + the @ Synchronized, then 3 methods with @ Override and @ SuppressWarnings, and 1 with just @ SuppressWarnings, adds up to exactly 10). The annotations don't need to be valid or even exist; as long as the parser recognizes them as an annotation, it counts. Yes. Huh?!???? |
👤 reinierz 🕗 Jun 13, 2011 at 21:04 UTC Adding fields is actually very very tricky; the positions have to be set to 0 or -1 (very carefully, some later math done by eclipse has to add up to exactly 0). However, this appears to be messing with the ability of eclipse to find the package statement, thus resulting in a type not found error as it thinks the type is named just "A" (default package) and not "foo.A" - also explaining why this error does not occur when all involved classes are in the default package. There is no short-term solution to this problem that we can see. Changing the positions to anything else causes the dreaded 'second AST' to attempt to reparse the field which will obviously fail as its not actually there. The long-term fix is to hook into that reparse, and prevent it if we detect that the field is generated. I recall we've done this before for other handlers, but @ Synchronized is by far the least-used and 0.10.0 is about half a year late, so pushed back to 0.10.1 |
👤 reinierz 🕗 Jun 21, 2011 at 14:13 UTC Might this be caused by something similar to issue #114? |
👤 grootjans 🕗 Jul 18, 2011 at 21:46 UTC |
👤 andreas.muenstermann@web.de 🕗 Jul 19, 2011 at 07:12 UTC Is there any update to this issue? When can we expect a bug fix? |
👤 reinierz 🕗 Jul 19, 2011 at 16:31 UTC Lets work around this by removing the suppress warnings annotation in 0.10.0 and add a more thorough fix in 0.10.1. |
👤 reinierz 🕗 Jul 25, 2011 at 18:24 UTC Worked around as promised; now @ Synchronized does not produce a @ SuppressWarnings annotation on the $LOCK/$lock field. We'll revisit this issue once we figure out how to add those safely to fields without causing half of the eclipse features to break. Done in dfca0e4 and will be rolled out in 0.10.0-RC2. Going to keep this issue open on low priority. |
👤 tomkedem 🕗 Feb 07, 2014 at 14:24 UTC Hey, it's been two and a half years. Will you get to it someday? |
👤 r.spilker 🕗 Feb 07, 2014 at 15:33 UTC I really cannot promise anything. As said before, it is not easy. Since yesterday, we do have a better infrastructure to debug eclipse. But That;s only one small step to fixing the problem. |
End of migration |
Surely this is no longer relevant. |
added simple test added changelog fixed projectlombok#290
Migrated from Google Code (issue 217)
The text was updated successfully, but these errors were encountered: