• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

hashCode function  RSS feed

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i have the snippet of code od SCJP book
Which code, when inserted at (1), will provide a correct implementation of the
hashCode() method in the following program?

Select the two correct answers.
(a) return 31337;
(b) return accumulated / count;
(c) return (count << 16) ^ accumulated;
(d) return ~accumulated;
(e) return count == 0 ? 0 : average();
the correct answer is (a) and (e)
(b) is incorrect because of count if it is null it will genearte arithmetic Exception
but i don't now the mean of (c) and (d) and why are false
 
Marshal
Posts: 64171
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

emma roberts wrote:. . . (b) is incorrect because of count if it is null it will genearte arithmetic Exception

But count can't be null. It is a primitive and primtives can't be null. It might be 0, however, in which case you will get such an exception.

but i don't now the mean of (c) and (d) and why are false

Work out what will happen if your accumulated value is 288 and you have a count of 16. Then change the accumulated value to 289 and see what happens. Hint: 288 ÷ 16 = 18.
 
emma roberts
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
please i still hava a difficult to undrestand the mean of (c) and (d) and why they are wrong
 
Ranch Hand
Posts: 3218
19
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For both (c) and (d), the problem is that they are not consistent with the implementation of equals().  You need to study how the equals() method is implemented, and compare that with the possible implementations of hashCode().  We can see that the equals() method uses count and average() - it doesn't use accumulated at all.  So right away, it should cause some concern if we see a hashCode() implementation that uses accumulated - such as b, c, or d.  The question is, is there any way that you can have two instances that are equal, as far as equals() is concerned, but have different hashcodes?  Because that is not allowed.

(The converse, instances that are not equal but have the same hashcode, is allowed - it's just inefficient.  So we ignore that case here.)

Consider two instances a and b:

What will happen if we run this, with code from (b), (c), or (d)? (Or (a) or (e)?)  Will the results make sense?  Try compiling and running the code yourself to see.
 
a fool thinks himself to be wise, but a wise man knows himself to be a fool - shakespeare. foolish tiny ad:
Create Edit Print & Convert PDF Using Free API with Java
https://coderanch.com/wiki/703735/Create-Convert-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!