Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 1088665
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 16, 20262026-05-16T23:06:11+00:00 2026-05-16T23:06:11+00:00

from p.46 Effective Java Joshua Bloch. Item 9: ALways override hashCode when you override

  • 0

from p.46 “Effective Java” Joshua Bloch. Item 9: ALways override hashCode when you override equals

  • Some class PhoneNumber overrides equals() and doesn’t override hashCode()
  • “two instances are involved: one is used for insertion into the HashMap, and a second, equal, instance is used for (attempted) retrieval.”
    …
    “… Even if the two instances happen to hash to the same bucket, the get method will almost certainly return null , as HashMap has an optimization that caches the hash code associated with each entry and doesn’t bother checking for object equality if the hash codes doesn’t match.”

The questions is
– why ‘get’ will return ‘null’ if “the two instances happen to hash to the same bucket”?

  • what is the role (in not getting the right instance) of the HashMap optimization “that cashes…”?

  • Just for the case – “the two instances happen to hash to the same bucket”- what if HashMap bothers about “object equality if the hash codes doesn’t match”?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-16T23:06:12+00:00Added an answer on May 16, 2026 at 11:06 pm

    Why ‘get’ will return ‘null’ if “the two instances happen to hash to the same bucket”? What is the role (in not getting the right instance) of the HashMap optimization “that cashes…”?

    The key sentence is

    […] doesn’t bother checking for object equality if the hash codes doesn’t match.

    So even if the keys hash to the same bucket, .equals may not be invoked (due to the caching optimizations) for the relevant element (since not even the hash-codes matches). Thus, even if the relevant element resides in the same bucket, it may never be compared through .equals, and thus not “found”.

    Just for the case – “the two instances happen to hash to the same bucket”- what if HashMap bothers about “object equality if the hash codes doesn’t match”?

    If it didn’t have this optimization, and actually did check .equals on all elements in the corresponding bucket and if the two hashes happened to hash to the same bucket, then the get-method would return the correct element. (But this would be pure luck, since if the objects aren’t equal, then there is no guarantee that the two hashes will map to the same bucket in the first place.)

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

Consider the following from Effective Java Item 11 (Override clone judiciously) where Josh Bloch
I read Effective Java by Joshua Bloch and removed the 'Constant Interface anti-pattern' from
I'm referring to the paradigm in Item 34 in Effective Java by Joshua Bloch.
I was reading through Item 15 of Effective Java by Joshua Bloch. Inside Item
From Effective Java Second Edition, Item 28 : Do not use wildcard types as
From Effective Java 2nd edition item 67 page 266-268: The background thread calls s.removeObserver
I have been reading Effective Java by Joshua Bloch and so far it really
In his book Effective Java , Joshua Bloch recommends against using Interfaces to hold
From Effective Java 2ed Item 2: telescoping constructor pattern, in which you provide a
From Effective Java ( Item 1 : Consider static factory methods instead of constructors

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.