But that generates lots of temp arrays... it's just as easy to use an IDE code generator to create the methods... I'll try that tomorrow [AFK ATM]
Gary On Sep 21, 2016 12:23 AM, "Greg Thomas" <greg.d.tho...@gmail.com> wrote: > Though, on reflection, (no pun intended), the Objects class *is* in Java > 7; https://docs.oracle.com/javase/7/docs/api/java/util/Objects.html > > It makes implement .equals and .hashcode trivial; > > Assuming a TestClass with three fields, foo, bar and foobar, you have ... > > @Override > public int hashCode() { > return Objects.hash(foo, bar, foobar); > } > > and ... > > @Override > public boolean equals(final Object o) { > if (!o == instanceof TestClass ) { > return false; > } > > final TestClass that = (TestClass) o; > return Objects.equals(this.foo, that.foo) && Objects.equals(this.bar, > that.bar) && Objects.equals(this.foobar, that.foobar); > } > > > > On 21 September 2016 at 03:17, Remko Popma <remko.po...@gmail.com> wrote: > >> Sorry I was thinking of Long.hashCode(long), but I see now that this was >> introduced in java 1.8... >> >> Sent from my iPhone >> >> On 2016/09/21, at 10:09, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Where do you see such a method? >> >> Gary >> >> On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma <remko.po...@gmail.com> >> wrote: >> >>> Objects.hashCode(long) does exactly the same, but is certainly easier to >>> read. Go for it! >>> >>> Sent from my iPhone >>> >>> On 2016/09/21, at 5:06, Greg Thomas <greg.d.tho...@gmail.com> wrote: >>> >>> Could you use simply >>> >>> return Objects.hashcode(...) >>> >>> To avoid the maths In the first place ?? >>> -- >>> Sent from my iPhone >>> >>> On 20 Sep 2016, at 19:53, Gary Gregory <garydgreg...@gmail.com> wrote: >>> >>> I see a Findbugs error in: >>> >>> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode() >>> >>> for: >>> >>> result = 31 * result + (threadPriority ^ (threadPriority >>> >>> 32)); >>> >>> "The code performs shift of a 32 bit int by a constant amount outside >>> the range -31..31. The effect of this is to use the lower 5 bits of the >>> integer value to decide how much to shift by (e.g., shifting by 40 bits is >>> the same as shifting by 8 bits, and shifting by 32 bits is the same as >>> shifting by zero bits). This probably isn't what was expected, and it is at >>> least confusing." >>> >>> Thoughts? >>> >>> Gary >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >
