«

Is it always technically correct to override the hashCode function like so:

@Override
public int hashCode() {
return 1;
}

Would it be potentially better if that was Object's implementation?

On 8/10/2012 11:47 AM, bob smith wrote:
> Is it always technically correct to override the hashCode function like so:
>
> @Override
> public int hashCode() {
> return 1;
> }

It meets the minimum contractual obligation for that method.

But performance of anything using the hash capability (like HashMap<>)
would be very bad.

> Would it be potentially better if that was Object's implementation?

It has a different behavior that may not be valid if you override equals.

Arne

On 8/10/2012 11:47 AM, bob smith wrote:
> Is it always technically correct to override the hashCode function like so:
>
> @Override
> public int hashCode() {
> return 1;
> }
>
> Would it be potentially better if that was Object's implementation?

Define "better."

--
Eric Sosman
d

On 8/10/2012 9:13 AM, Arne Vajhøj wrote:
> On 8/10/2012 11:47 AM, bob smith wrote:
>> Is it always technically correct to override the hashCode function
>> like so:
>>
>> @Override
>> public int hashCode() {
>> return 1;
>> }
>
> It meets the minimum contractual obligation for that method.
>
> But performance of anything using the hash capability (like HashMap<>)
> would be very bad.
>
>> Would it be potentially better if that was Object's implementation?
>
> It has a different behavior that may not be valid if you override equals.


I think at this point we are doing Bob's homework for him.

On 8/10/2012 1:13 PM, markspace wrote:
> On 8/10/2012 9:13 AM, Arne Vajhøj wrote:
>> On 8/10/2012 11:47 AM, bob smith wrote:
>>> Is it always technically correct to override the hashCode function
>>> like so:
>>>
>>> @Override
>>> public int hashCode() {
>>> return 1;
>>> }
>>
>> It meets the minimum contractual obligation for that method.
>>
>> But performance of anything using the hash capability (like HashMap<>)
>> would be very bad.
>>
>>> Would it be potentially better if that was Object's implementation?
>>
>> It has a different behavior that may not be valid if you override equals.
>
> I think at this point we are doing Bob's homework for him.

Could be.

But I think the question whether returning a constant from
hashCode is a valid Java question for understanding the
contract for that method.

And I am pretty sure that I have seen other similar
examples (just with 42 as constant).

Arne

On Fri, 10 Aug 2012 08:47:12 -0700 (PDT), bob smith
<> wrote, quoted or indirectly quoted someone
who said :

> @Override
> public int hashCode() {
> return 1;
> }

that's about the worst possible hashCode function.

See http://mindprod.com/jgloss/hashcode.html for tips on how to write
good ones.
--
Roedy Green Canadian Mind Products http://mindprod.com
A new scientific truth does not triumph by convincing its opponents and making them see the light,
but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
~ Max Planck 1858-04-23 1947-10-04

Roedy Green wrote:
> bob smith wrote, quoted or indirectly quoted someone
> who said :
>
>> @Override
> > public int hashCode() {
> > return 1;
> > }
>
> that's about the worst possible hashCode function.

Normally that's correct, but it's conceivable that one might do it for
some hackish reason. In most situations where one might do such
an override as this, one would do better not to override hashCode().

> See http://mindprod.com/jgloss/hashcode.html for tips on how to write
> good ones.

The default of assembling it via the mix-in of attribute hash codes
using the Knuth constants is usually good enough.

h(object) = Sum(i ∈ 0.. n-1) of ( attribute[i] * pow(31, n - 1 - i) );

or

public static int calculateHash(Foo arg) {
int h = 0;

for ( each attribute of Foo that contributes to 'equals()' )
{
h = 31 * h + attribute.hashCode();
}
return h;
}

http://en.wikipedia.org/wiki/Hash_function
http://en.wikipedia.org/wiki/Java_hashCode()
http://en.wikipedia.org/wiki/Java_hashCode()#Java

--
Lew

On Friday, August 10, 2012 11:34:28 AM UTC-5, Eric Sosman wrote:
> On 8/10/2012 11:47 AM, bob smith wrote:
>
> > Is it always technically correct to override the hashCode function like so:
>
> >
>
> > @Override
>
> > public int hashCode() {
>
> > return 1;
>
> > }
>
> >
>
> > Would it be potentially better if that was Object's implementation?
>
>
>
> Define "better."
>
>
>
> --
>
> Eric Sosman
>
> d

Better in the sense that you would never HAVE to override hashCode.

Now, there are cases where you HAVE to override it, or your code is very broken.

bob smith wrote:
> Eric Sosman wrote:
>> bob smith wrote:
>>> Is it always technically correct to override the hashCode function like so:

It complies with the contract for 'hashCode()'. Is that all it takes to be correct?

>>> Would it be potentially better if that was Object's implementation?

Would what be better if what were Object's implementation of what?

>> Define "better."

> Better in the sense that you would never HAVE to override hashCode.
>
> Now, there are cases where you HAVE to override it, or your code is very broken.

No.

No matter what 'Object''s 'hashCode()' implementation were, it would need to
be overridden when you want value equality instead of object identity for
'equals()'.

See Joshua Bloch's seminal work /Effective Java/, which has items that pertain to this.

Bottom line: 'hashCode()', 'equals()', and when present, 'compareTo()' must be consistent.

'toString()' should be consistent with those.

As long as 'hashCode()' fulfills the contract, your code will work - functionally. But a bad
'hashCode()' could and likely will noticeably affect performance. There is more to correctness
than mere functional conformance.

--
Lew

On 8/10/2012 3:17 PM, Roedy Green wrote:
> On Fri, 10 Aug 2012 08:47:12 -0700 (PDT), bob smith
> <> wrote, quoted or indirectly quoted someone
> who said :
>
>> @Override
>> public int hashCode() {
>> return 1;
>> }
>
> that's about the worst possible hashCode function.

Yes, but the posted asked "Is it always technically correct to ..."
not whether is was "best possible".

Arne