Migrated from Google Code (issue 366)
👤 k.tinnefeld 🕗 Apr 21, 2012 at 09:48 UTC
In a lombok-generated equal, we read
if (this.getName() == null ? other.getName() != null : !this.getName().equals((java.lang.Object)other.getName())) return false;
This gives me a bad feeling about calling a method (be it "just" a getter) twice. Even though there are workarounds (lazy getters for finals and the option to read fields directly), I would suggest - at least as an option - to generate sth like
final java.lang.Object $lombok$eq$t$name = this.getName();
final java.lang.Object $lombok$eq$o$name = other.getName();
if ($lombok$eq$t$name == null ? $lombok$eq$o$name != null : !$lombok$eq$t$name.equals($lombok$eq$o$name)) return false;
final SimpleModel other = (SimpleModel)o;
if (!other.canEqual((java.lang.Object)this)) return false;
Shouldn't this be the other way round? No need to cast if canEqual() fails.
👤 k.tinnefeld 🕗 Apr 21, 2012 at 20:08 UTC
What version of the product are you using? On what operating system?
0.11.0 on Windows 7 64 Bit
👤 r.spilker 🕗 Apr 23, 2012 at 19:04 UTC
2nd point: We can't call canEqual without first casting; canEqual is not a method that java.lang.Object has. The way canEqual works, calling this.canEqual(o) doesn't do anything useful, the whole point of the call is to ask the other object.
As to point ﹟1: it is a good idea to only call the getter on the this object only once and store the result in a local variable. There is no need to also call the call to the other object since it will only be called once anyway, albeit on two different locations.
For the naming of the local variable: we can just use one simple name like "object" and use it for all the fields containing an object reference.
👤 r.spilker 🕗 Apr 23, 2012 at 19:06 UTC
We should also call the getter in hashCode only once as well.
👤 k.tinnefeld 🕗 Apr 24, 2012 at 20:13 UTC
Sure, forget about 2nd.
We should also call the getter once in LONG.equals. I chose "field" over "object" as field name, though.
The attachment does the javac changes, didn't look into the eclipse code too deep yet.
👤 r.spilker 🕗 Apr 25, 2012 at 08:57 UTC
Thanks for dedicating the time to create a patch. In the mean time we've been working on this issue as well. To prevent double work, next time please contact us through the issue if you plan to create a patch.
In our implementation we've modified the following:
If you plan to create a patch in the future, which is highly appreciated, please clone the github repository, and add your name to the AUTHORS file as well. That way we can also ensure we don't run into legal problems in the future. And we can give feedback before integrating it into Lombok.
👤 r.spilker 🕗 Apr 25, 2012 at 08:58 UTC
We still need to work on the Eclipse implementation, so the source is not yet pushed to github.
👤 r.spilker 🕗 Apr 29, 2012 at 21:59 UTC
Fixed in 25def86
End of migration