Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #17577 > unrolled thread

hashCode

Back to article view | Back to comp.lang.java.programmer

Contents

  hashCode bob smith <bob@coolfone.comze.com> - 2012-08-10 08:47 -0700
    Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 12:13 -0400
      Re: hashCode markspace <-@.> - 2012-08-10 10:13 -0700
        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 13:38 -0400
          Re: hashCode rossum <rossum48@coldmail.com> - 2012-08-11 10:36 +0100
    Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-10 12:34 -0400
      Re: hashCode bob smith <bob@coolfone.comze.com> - 2012-08-10 15:22 -0700
        Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-10 15:32 -0700
          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:30 -0400
            Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:24 -0700
              Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:15 -0400
                Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:29 -0400
                  Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 22:43 -0400
                    Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:54 -0400
                      Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 21:46 -0700
                        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 16:53 -0400
                        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:00 -0400
        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:27 -0400
          Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-12 17:06 +0200
            Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 16:59 -0400
              Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-13 19:17 +0200
                Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-19 19:42 -0400
                  Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-21 10:30 +0000
                Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-19 19:47 -0400
                  Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-21 10:43 +0000
                    Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 19:04 -0400
                      Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-27 16:55 -0700
                        Re: hashCode markspace <-@.> - 2012-08-27 17:03 -0700
                          Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-27 17:49 -0700
                          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 21:37 -0400
                          Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-27 18:58 -0700
                            Re: hashCode markspace <-@.> - 2012-08-27 21:19 -0700
                              Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-28 01:06 -0700
                                Re: hashCode markspace <-@.> - 2012-08-28 09:19 -0700
                                  Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-28 16:33 -0700
                                    Re: hashCode markspace <-@.> - 2012-08-28 17:02 -0700
                                      Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 11:06 -0700
                                        Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 14:49 -0400
                                          Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 13:40 -0700
                                            Re: hashCode Gene Wirchenko <genew@ocis.net> - 2012-08-29 18:02 -0700
                                          Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-08-31 00:52 +0200
                                            Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-30 21:43 -0400
                                              Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-30 21:52 -0400
                                              Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-08-31 04:18 +0200
                                                Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:08 -0600
                                                  Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 11:38 -0400
                                                    Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-31 17:55 +0200
                                                    Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:56 -0600
                                                      Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 14:32 -0400
                                                        Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 14:38 -0600
                                                      Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-31 15:33 -0700
                                                        Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 16:41 -0600
                                                          Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-31 16:26 -0700
                                                            Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-09-02 11:54 -0600
                                                              Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-09-03 00:47 +0200
                                                                Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-09-03 21:44 -0600
                                              Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:08 -0600
                                                Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-31 17:58 +0200
                                        Re: hashCode markspace <-@.> - 2012-08-29 11:51 -0700
                                          Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 13:28 -0700
                                            Re: hashCode markspace <-@.> - 2012-08-29 16:05 -0700
                                              Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 16:23 -0700
                                                Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 20:56 -0400
                                                  Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-30 11:19 +0200
                                                  Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-30 10:03 -0700
                                                    Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-30 18:34 +0000
                                              Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-30 08:11 -0600
                                                Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-30 10:06 -0700
                                              Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-30 19:16 -0400
                              Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 13:58 -0700
                            Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 13:56 -0700
                              Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-28 14:07 -0700
                                Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 14:38 -0700
                        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 21:12 -0400
        Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 07:58 -0400
          Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:29 -0700
            Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:16 -0400
        Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 03:46 -0700
        Re: hashCode Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-08-12 12:23 -0400
          Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 09:40 -0700
            Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-12 13:59 -0400
              Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 11:17 -0700
            Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:02 -0400
          Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 19:03 +0200
    Re: hashCode Roedy Green <see_website@mindprod.com.invalid> - 2012-08-10 12:17 -0700
      Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-10 12:45 -0700
        Re: hashCode Roedy Green <see_website@mindprod.com.invalid> - 2012-08-11 04:54 -0700
          Re: hashCode Joerg Meier <joergmmeier@arcor.de> - 2012-08-11 18:25 +0200
            Re: hashCode Mike Winter <usenet@michael-winter.me.invalid> - 2012-08-11 18:53 +0100
          Re: hashCode Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-08-11 09:56 -0700
          Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 18:58 +0200
          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:40 -0400
        Re: hashCode rossum <rossum48@coldmail.com> - 2012-08-11 18:47 +0100
      Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:25 -0400
        Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 08:00 -0400
          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 09:49 -0400
    Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 15:33 +0200
      Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 15:34 +0200
      Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:34 -0700
        Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:37 -0700
        Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:19 -0400
          Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 21:48 -0700
      Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 12:08 +0200
        Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 12:18 +0200
        Re: hashCode Lew <noone@lewscanon.com> - 2012-08-12 11:27 -0700
          Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:11 -0400

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#17577 — hashCode

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?

[toc] | [next] | [standalone]

#17578

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

[toc] | [prev] | [next] | [standalone]

#17581

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.

[toc] | [prev] | [next] | [standalone]

#17582

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

[toc] | [prev] | [next] | [standalone]

#17673

On Fri, 10 Aug 2012 13:38:19 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>And I am pretty sure that I have seen other similar
>examples (just with 42 as constant).
The magic word is "Bloch".

rossum

[toc] | [prev] | [next] | [standalone]

#17580

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
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#17660

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
> 
> esosman@ieee-dot-org.invalid

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.

[toc] | [prev] | [next] | [standalone]

#17662

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

[toc] | [prev] | [next] | [standalone]

#17671

On 8/10/2012 6:32 PM, Lew wrote:
> bob smith wrote:
>> Now, there are cases where you HAVE to override it, or your code is very broken.
>
> No.

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

If the code per specs is guaranteed to work then it is correct.

Good (or just decent) performance is not necessary for code to
be correct.

At least not in the traditional programming terminology.

In plain English maybe.

Arne

[toc] | [prev] | [next] | [standalone]

#17715

On 08/10/2012 04:30 PM, Arne Vajhøj wrote:
> On 8/10/2012 6:32 PM, Lew wrote:
>> bob smith wrote:
>>> Now, there are cases where you HAVE to override it, or your code is very
>>> broken.
>>
>> No.
>
>> 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.
>
> If the code per specs is guaranteed to work then it is correct.
>
> Good (or just decent) performance is not necessary for code to
> be correct.
>
> At least not in the traditional programming terminology.
>
> In plain English maybe.

I see your point, but that is not to say that the specs exclude performance 
considerations.

In the case of 'hashCode()', the Javadocs do say, "This method is supported 
for the benefit of hash tables such as those provided by HashMap."
<http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()>

The key question here is how you define "benefit". I argue that a hash code 
that is constant does not benefit, say, a 'HashMap' because one of our desired 
uses is constant-order retrieval.

"This implementation provides constant-time performance for the basic 
operations (get and put), assuming the hash function disperses the elements 
properly among the buckets."
<http://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html>

Each specification refers to the other. Ergo they are meant to be considered 
together. Taken together, the documentation clearly specifies that "correct" 
or "proper" includes performance considerations. Therefore, by what you say, 
the simple "return 1;" is not correct.

It certainly would not be correct for the 'Object' implementation.
"As much as is reasonably practical, the hashCode method defined by class 
Object does return distinct integers for distinct objects." [op. cit.]

As you say, Arne, "correct" means it follows the spec. The OP's suggested 
implementation violates the spec on two fronts.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#17720

On 8/11/2012 7:24 PM, Lew wrote:
> On 08/10/2012 04:30 PM, Arne Vajhøj wrote:
>> On 8/10/2012 6:32 PM, Lew wrote:
>>> bob smith wrote:
>>>> Now, there are cases where you HAVE to override it, or your code is
>>>> very
>>>> broken.
>>>
>>> No.
>>
>>> 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.
>>
>> If the code per specs is guaranteed to work then it is correct.
>>
>> Good (or just decent) performance is not necessary for code to
>> be correct.
>>
>> At least not in the traditional programming terminology.
>>
>> In plain English maybe.
>
> I see your point, but that is not to say that the specs exclude
> performance considerations.
>
> In the case of 'hashCode()', the Javadocs do say, "This method is
> supported for the benefit of hash tables such as those provided by
> HashMap."
> <http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()>
>
> The key question here is how you define "benefit". I argue that a hash
> code that is constant does not benefit, say, a 'HashMap' because one of
> our desired uses is constant-order retrieval.

Object having the method defined to support effective hashing
does not imply that it has to it just means that the potential
is there.

> "This implementation provides constant-time performance for the basic
> operations (get and put), assuming the hash function disperses the
> elements properly among the buckets."

Yes. And here it makes an assumption. Not that hashCode is implemented
correct, but that it is implemented in a certain way.

> Each specification refers to the other. Ergo they are meant to be
> considered together. Taken together, the documentation clearly specifies
> that "correct" or "proper" includes performance considerations.
> Therefore, by what you say, the simple "return 1;" is not correct.

> As you say, Arne, "correct" means it follows the spec. The OP's
> suggested implementation violates the spec on two fronts.

No it does not.

It follows exactly the explicit stated contract in the Java doc:

<quote>
  The general contract of hashCode is:

     Whenever it is invoked on the same object more than once during an 
execution of a Java application, the hashCode method must consistently 
return the same integer, provided no information used in equals 
comparisons on the object is modified. This integer need not remain 
consistent from one execution of an application to another execution of 
the same application.
     If two objects are equal according to the equals(Object) method, 
then calling the hashCode method on each of the two objects must produce 
the same integer result.
     It is not required that if two objects are unequal according to the 
equals(java.lang.Object) method, then calling the hashCode method on 
each of the two objects must produce distinct integer results. However, 
the programmer should be aware that producing distinct integer results 
for unequal objects may improve the performance of hashtables.
</quote>

The ability to support something does not make it part of the contract.

This is a classic test question in basic Java SE. And that returning
a constant is correct but not smart should be in most Java SE
text books.

Arne

[toc] | [prev] | [next] | [standalone]

#17723

On 8/11/2012 10:15 PM, Arne Vajhøj wrote:
> This is a classic test question in basic Java SE. And that returning
> a constant is correct but not smart should be in most Java SE
> text books.

Effective Java / Joshua Bloch:

<quote>
// The worst possible legal hash function - never use!
public int hashCode() { return 42; }

It is legal because it ensures that equal objects have the
same hash code. It's atrocious because ...
</quote>

Java 2 SUN Certified Programmer & Developer / Kathy Sierra & Bert Bates:

<quote>
A hashCode() that returns the same value for all instances whether
they're equal or not is still a legal - even appropriate - hashCode()
method! For example,
public int hashCode() {
     return 1492;
}
would not violate the contract
...
This hashCode() method is horrible inefficient, ...
...
Nontheless, this one-hash-fits-all method would be
considered appropriate and even correct because it
doesn't violate the contract. Once more, correct does
not necessarily mean good.
</quote>

Arne

[toc] | [prev] | [next] | [standalone]

#17725

On 8/11/2012 10:29 PM, Arne Vajhøj wrote:
> On 8/11/2012 10:15 PM, Arne Vajhøj wrote:
>> This is a classic test question in basic Java SE. And that returning
>> a constant is correct but not smart should be in most Java SE
>> text books.
>
> Effective Java / Joshua Bloch:
>
> <quote>
> // The worst possible legal hash function - never use!
> public int hashCode() { return 42; }
>
> It is legal because it ensures that equal objects have the
> same hash code. It's atrocious because ...
> </quote>
>
> Java 2 SUN Certified Programmer & Developer / Kathy Sierra & Bert Bates:
>
> <quote>
> A hashCode() that returns the same value for all instances whether
> they're equal or not is still a legal - even appropriate - hashCode()
> method! For example,
> public int hashCode() {
>      return 1492;
> }
> would not violate the contract
> ...
> This hashCode() method is horrible inefficient, ...
> ...
> Nontheless, this one-hash-fits-all method would be
> considered appropriate and even correct because it
> doesn't violate the contract. Once more, correct does
> not necessarily mean good.
> </quote>

     All this means is that people know how to describe a "correct"
hashCode(), but nobody knows how to describe a "usable" hashCode()
in terms that apply testably to all circumstances.

     The O.P. asked whether it would "be potentially better" if
Object's hashCode() returned a constant.  He did *not* ask whether
such an implementation would be correct; he only asked if it would
"be potentially better."  Upon prompting he explained what he
meant by "better," and in light of that explanation the answer
to his original question is NO.  Discussions about "Oh, but it's
CORRECT" are just red herrings; it's still not "better."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#17726

On 8/11/2012 10:43 PM, Eric Sosman wrote:
>      The O.P. asked whether it would "be potentially better" if
> Object's hashCode() returned a constant.  He did *not* ask whether
> such an implementation would be correct; he only asked if it would
> "be potentially better."  Upon prompting he explained what he
> meant by "better," and in light of that explanation the answer
> to his original question is NO.  Discussions about "Oh, but it's
> CORRECT" are just red herrings; it's still not "better."


The original questions were:

#Is it always technically correct to override the hashCode function 
#like so:
#
#	@Override
#	public int hashCode() {
#		return 1;
#	}

For which the answer is YES. Per documentation.

But with really poor performance in many relevant cases.

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

Which was clarified to:

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

For which the answer is also YES. Per the previous.

But with the same performance note. And a big sigh because it
seems to want to broaden bad performance from a single class
to the entire programming style (multiple classes).

Arne

[toc] | [prev] | [next] | [standalone]

#17727

Arne Vajhøj wrote:
> The original questions were:
>
> #Is it always technically correct to override the hashCode function #like so:
> #
> #    @Override
> #    public int hashCode() {
> #        return 1;
> #    }
>
> For which the answer is YES. Per documentation.
>
> But with really poor performance in many relevant cases.
>
> #Would it be potentially better if that was Object's implementation?
>
> Which was clarified to:
>
> #Better in the sense that you would never HAVE to override hashCode.
>
> For which the answer is also YES. Per the previous.

No, that's not true. Value-equality maps, for example, would not work if you 
didn't override 'hashCode()' in the key type to match value equality on the keys.

> But with the same performance note. And a big sigh because it
> seems to want to broaden bad performance from a single class
> to the entire programming style (multiple classes).

Overriding 'hashCode()' is done for functional reasons, not performance 
reasons. If you fail to override the method, you'll get incorrect behavior, 
for example failing to find a collection member that is actually present.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#17764

On 8/12/2012 12:46 AM, Lew wrote:
> Arne Vajhøj wrote:
>> The original questions were:
>>
>> #Is it always technically correct to override the hashCode function
>> #like so:
>> #
>> #    @Override
>> #    public int hashCode() {
>> #        return 1;
>> #    }
>>
>> For which the answer is YES. Per documentation.
>>
>> But with really poor performance in many relevant cases.
>>
>> #Would it be potentially better if that was Object's implementation?
>>
>> Which was clarified to:
>>
>> #Better in the sense that you would never HAVE to override hashCode.
>>
>> For which the answer is also YES. Per the previous.
>
> No, that's not true. Value-equality maps, for example, would not work if
> you didn't override 'hashCode()' in the key type to match value equality
> on the keys.

That was almost exactly what I answered in my first answer to
the original poster.

Then I read it as "would it be better if my class used Object's
implementation".

But after reading the clarification then I think it should be
read as "would it be better if Object used the implementation
shown".

Very different question!

Arne

[toc] | [prev] | [next] | [standalone]

#17766

On 8/12/2012 12:46 AM, Lew wrote:
> Arne Vajhøj wrote:
>> But with the same performance note. And a big sigh because it
>> seems to want to broaden bad performance from a single class
>> to the entire programming style (multiple classes).
>
> Overriding 'hashCode()' is done for functional reasons, not performance
> reasons. If you fail to override the method, you'll get incorrect
> behavior, for example failing to find a collection member that is
> actually present.

Correct.

But the return constant is a special case. It functions as it
should but performs very poorly.

Arne

[toc] | [prev] | [next] | [standalone]

#17669

On 8/10/2012 6:22 PM, bob smith wrote:
> 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."
>
> 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.

It is not broken.

It will perform poorly in many cases.

Arne

[toc] | [prev] | [next] | [standalone]

#17733

On 11.08.2012 01:27, Arne Vajhøj wrote:
> On 8/10/2012 6:22 PM, bob smith wrote:
>> 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."
>>
>> 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.
>
> It is not broken.
>
> It will perform poorly in many cases.

Well, I would go as far as to say that it will perform poorly in all 
cases where hashCode() is actually needed - and that makes it broken. 
The whole idea of hashing is based on the fact that the hash code 
_somehow_ represents the item to be hashed.  If all items have the same 
constant hash code there is no point in hashing at all.  So while it 
does work, it does not work as intended.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#17765

On 8/12/2012 11:06 AM, Robert Klemme wrote:
> On 11.08.2012 01:27, Arne Vajhøj wrote:
>> On 8/10/2012 6:22 PM, bob smith wrote:
>>> 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."
>>>
>>> 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.
>>
>> It is not broken.
>>
>> It will perform poorly in many cases.
>
> Well, I would go as far as to say that it will perform poorly in all
> cases where hashCode() is actually needed

More or less.

>                                        - and that makes it broken.

This thread started about whether it is correct. The term correct
has a very specific meaning in programming and that always return 1
code is correct.

Now you talk about broken. If broken means not good, then you are right.
If broken means not correct, then you are wrong. I suspect
that broken is not very well defined.

> The whole idea of hashing is based on the fact that the hash code
> _somehow_ represents the item to be hashed.  If all items have the same
> constant hash code there is no point in hashing at all.  So while it
> does work, it does not work as intended.

It disable the entire hashing functionality and a HashMap get
characteristics of ArrayList.

But the code should actually work.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web