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

Reply via email to