1 2 Previous Next 24 Replies Latest reply: Feb 2, 2010 5:52 AM by 807580 RSS

    Is value returned by java.lang.Object.hashCode( ) unique?

    807580
      Can hashCode( ) return the same value for 2 different objects, given that I have not overridden this API in my objects?

      The documentation for hashCode says "This is typically implemented by converting the internal address of the object into an integer". I wanted to know the actual implementation of this API in the sun JVM.

      Also I wnated to know the outcome of the following:
      1. Object A is in location X
      2. A.hashCode( ) is invoked.
      3. Garbage collector moves A from X to location Y
      4. Object B is created in location x
      5. B.hashCode( ) is invoked.

      Are the hash codes in the above case always same?
        • 1. Re: Is value returned by java.lang.Object.hashCode( ) unique?
          807580
          Also I wnated to know the outcome of the following:
          1. Object A is in location X
          Objects don't have any locations, so the other points are moot.
          2. A.hashCode( ) is invoked.
          3. Garbage collector moves A from X to location Y
          4. Object B is created in location x
          5. B.hashCode( ) is invoked.

          Are the hash codes in the above case always same?
          They may be. A well behaved JVM may return a constant value (say 0) for all objects that don't override hashCode().

          With kind regards
          Ben
          • 2. Re: Is value returned by java.lang.Object.hashCode( ) unique?
            JoachimSauer
            harihawking wrote:
            Can hashCode( ) return the same value for 2 different objects, given that I have not overridden this API in my objects?
            Yes. In fact I've had that exact question some time ago and verified that two objects can easily return the same value here.

            It's much more likely if one of those objects is no longer live (i.e. it has been or could have been GCed), but it can also happen while both objects are alive.

            That's easily proven by the fact that current computer architectures allow for an amount of ram that easily allows more distinct objects than an int has different values.
            The documentation for hashCode says "This is typically implemented by converting the internal address of the object into an integer".
            I think this sentence is dangerous. Especially since I have a strong suspicion that it is no longer true in current JVMs. The memory occupied by the fields of some object can be moved during the lifetime of the object.
            I wanted to know the actual implementation of this API in the sun JVM.
            Check the source. It's the only way to know for sure.

            >
            Also I wnated to know the outcome of the following:
            1. Object A is in location X
            2. A.hashCode( ) is invoked.
            3. Garbage collector moves A from X to location Y
            Since this doesn't change the return value of A.hashCode() (otherwise it would be a violation of the contract) we know that the concrete location does not influence the return value of hashCode().

            Also note that some GC implementations may not move objects.
            4. Object B is created in location x
            5. B.hashCode( ) is invoked.

            Are the hash codes in the above case always same?
            The value returned is usually distinct from the one returned by A.hashCode(). That's not a very strong guarantee, but it's the only one you can get.
            • 3. Re: Is value returned by java.lang.Object.hashCode( ) unique?
              JoachimSauer
              BenSchulz wrote:
              Are the hash codes in the above case always same?
              They may be. A well behaved JVM may return a constant value (say 0) for all objects that don't override hashCode().
              That might be a conforming JVM, but I wouldn't call it well-behaved at all, since the JavaDoc specifically says this:
              As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.
              • 4. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                807580
                That might be a conforming JVM, but I wouldn't call it well-behaved at all [...]
                Obviously I would.. ;)

                With kind regards
                Ben
                • 5. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                  807580
                  Crosspost.
                  [http://forums.sun.com/thread.jspa?threadID=5426286]
                  • 6. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                    JoachimSauer
                    BenSchulz wrote:
                    That might be a conforming JVM, but I wouldn't call it well-behaved at all [...]
                    Obviously I would.. ;)
                    So equating "As much as reasonably practical" with "Never" would be considered well-behaved? No offense meant, but I wouldn't want to work with a JVM that was designed according to that paradigm ;-)
                    • 7. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                      807580
                      So equating "As much as reasonably practical" with "Never" would be considered well-behaved? No offense meant, but I wouldn't want to work with a JVM that was designed according to that paradigm ;-)
                      I would define well-behaved as not violating the specification, which such an implementation would not. I did not take offense and mean to give no either, I just like things to be precise and correct. ;)

                      With kind regards
                      Ben
                      • 8. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                        JoachimSauer
                        BenSchulz wrote:
                        So equating "As much as reasonably practical" with "Never" would be considered well-behaved? No offense meant, but I wouldn't want to work with a JVM that was designed according to that paradigm ;-)
                        I would define well-behaved as not violating the specification, which such an implementation would not.
                        Oh, I see. That's where our definitions differ: my "well-behaved" extends quite a bit beyond "specification-conform" and also includes putting some effort into fulfilling optional requirements such as this one. Attempted fail-fast behavior of iterators is another point where I'd say that a well-behaved JVM would at least try to be conformant, while a specification-conforming JVM doesn't need to do anything.
                        I did not take offense and mean to give no either, I just like things to be precise and correct. ;)
                        I didn't think that you gave or took any offence either.
                        • 9. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                          807580
                          JoachimSauer wrote:
                          That's where our definitions differ:
                          my "well-behaved" extends quite a bit beyond "specification-conform" and also includes putting some effort into fulfilling optional requirements such as this one. Attempted fail-fast behavior of iterators is another point where I'd say that a well-behaved JVM would at least try to be conformant, while a specification-conforming JVM doesn't need to do anything.
                          specification conformance - does that mean just JLS and JVM spec or does it include the Java API?
                          The JLS says refer to the Java API.
                          • 10. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                            807580
                            Thats why one way to make hashcode safe is to override the method as follows:-
                                 @Override
                                 public int hashCode() {
                                      final int prime = 31;
                                      int result;
                                      result = prime * result + ((param1 == null) ? 0 : param1.hashCode());
                                      result = prime * result + ((param2 == null) ? 0 : param2.hashCode());
                                      return result;
                                 }
                            where param1 and param2 are members of the class. HTH
                            • 11. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                              807580
                              where param1 and param2 are members of the class.
                              Which don't change after hashCode() is first called and whose classes implement hashCode() correctly as well.

                              With kind regards
                              Ben
                              • 12. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                                807580
                                BenSchulz wrote:
                                where param1 and param2 are members of the class.
                                Which don't change after hashCode() is first called and whose classes implement hashCode() correctly as well.

                                With kind regards
                                Ben
                                Well they would change each time the object is instantiated/initialized or if the state is changed unless the object is immutable.

                                Edited by: kilyas on Feb 1, 2010 2:34 PM
                                • 13. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                                  807580
                                  Well they would change each time the object is instantiated/initialized or if the state is changed unless the object is immutable.
                                  Absolutely; I just wanted to insinuate that defining hashCode() and equals() for mutable objects is never safe.

                                  With kind regards
                                  Ben
                                  • 14. Re: Is value returned by java.lang.Object.hashCode( ) unique?
                                    807580
                                    BenSchulz wrote:
                                    Well they would change each time the object is instantiated/initialized or if the state is changed unless the object is immutable.
                                    Absolutely; I just wanted to insinuate that defining hashCode() and equals() for mutable objects is never safe.

                                    With kind regards
                                    Ben
                                    well overriding hashcode and equals method is not unsafe since when the state of the object changes so would the hashcode, what is unsafe is using a such an object(mutable) as a key in one of the hash based collections. IMHO
                                    1 2 Previous Next