Eclipse can not resolve class dependency with classes that uses @Synchronized

[lombokissues]

Migrated from Google Code (issue 217)

[lombokissues]

👤 andreas.muenstermann@web.de   🕗 Jun 08, 2011 at 11:12 UTC

What steps will reproduce the problem?

1. create a class A with a method annotated with @ Synchronized
2. create another class B within the same package that refers to the first class A
3. The eclipse IDE will mark the reference with "cannot resolve class B"

What version of the product are you using? On what operating system?
Lombok 0.9.3
Eclipse Helios SR2

Please provide any additional information below.

[lombokissues]

👤 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;

• doesn't happen in the default package
• the error doesn't appear in the problem overview, only in the class file view itself.

[lombokissues]

👤 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?!????

[lombokissues]

👤 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

[lombokissues]

👤 reinierz   🕗 Jun 21, 2011 at 14:13 UTC

Might this be caused by something similar to issue #114?

[lombokissues]

👤 grootjans   🕗 Jul 18, 2011 at 21:46 UTC

[lombokissues]

👤 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?

[lombokissues]

👤 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.

[lombokissues]

👤 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.

[lombokissues]

👤 tomkedem   🕗 Feb 07, 2014 at 14:24 UTC

Hey, it's been two and a half years. Will you get to it someday?
I'm more interested in the application of this solution for issue #637.

[lombokissues]

👤 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.

[lombokissues]

End of migration

[rzwitserloot]

Surely this is no longer relevant.