Migrated from Google Code (issue 48)
👤 reinierz 🕗 Sep 15, 2009 at 07:22 UTC
Presumably something @ Data does.
👤 r.spilker 🕗 Sep 15, 2009 at 09:58 UTC
Actually, fixing issue #120 would
take care of this.
👤 reinierz 🕗 Sep 15, 2009 at 11:54 UTC
It would, but, there's a bug here which is why its a separate issue: ALL field access should be qualified (with
this.), to avoid namespace clashes with e.g. a statically imported field. Sure, that would be rare, but nevertheless,
all generated field accesses should always be of the 'this.foo' form.
Status is 'new' because I'm pretty sure we DO qualify all accesses. First need to find out where we're forgetting it.
👤 firstname.lastname@example.org 🕗 Sep 15, 2009 at 21:54 UTC
//Using lombok 0.8.5
👤 reinierz 🕗 Sep 23, 2009 at 05:46 UTC
Fixed in 35691e8 - should be live in the next major lombok release (I'm
guessing it'll be called v0.9 the way things are looking right now).
👤 email@example.com 🕗 Mar 14, 2010 at 21:58 UTC
I am afraid I still experience this bug, though now on a different annotation.
In my eclipse dir:
$ java -jar lombok.jar --version
In projects classpath:
// Using lombok 0.9.2
This also happens on others.
Know I wonder: Did you miss this one while fixing the other or do I fail at upgrading?
Attached you will find three files (test cases, though not automated) of which only
the second succeeds.
👤 reinierz 🕗 Mar 15, 2010 at 22:56 UTC
We probably forgot to catch it. We don't have the 'unqualified access' warning on, and a conflict is rare. We'll get
around this fixing this.
👤 reinierz 🕗 Jul 17, 2010 at 22:36 UTC
We double checked everything - as far as I can tell they're all qualified now. Notably including @ Synchronized, where this technically could even lead to faulty generated code if you have a parameter named $lock.
See commit 8869e97
End of migration