Is there really a problem to solve here? The code to compute the hashCode for a long is actually the canonical way to do this, documented in Effective Java. FindBugs is complaining about nothing...
Sent from my iPhone > On 2016/09/21, at 18:02, Gary Gregory <garydgreg...@gmail.com> wrote: > > 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 >>>>>>> JUnit in Action, Second Edition >>>>>>> Spring Batch in Action >>>>>>> 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 >>>> JUnit in Action, Second Edition >>>> Spring Batch in Action >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory
