• Post Reply Bookmark Topic Watch Topic
  • New Topic

Isn't it true that 'new' keyword always create a new object when used?  RSS feed

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Isn't it true that whenever we create objects with "new" keyword a new object is created by JVM every time ? If the above statement is true then there hashcodes must be different right?
 
Saloon Keeper
Posts: 3330
46
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, new creates a new object. No, the hash codes do not have to be unique.

Consider that a hash code is an int with 32bits, what happens when you get the hash code for a Long? The data for a Long is 64bits but its hash code is still only 32bits - impossible to have a one-to-one relationship. Hash codes apply some algorithm to condense an object down to a hopefully evenly distributed int. For classes you design yourself you can override the hashCode() method. You could have it return the int '1' all the time. It would work but be INCREDIBLY inefficient.
 
sathya reddy
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what i mean is if you create two objects using "new" keyword then there hashcodes must be different ?

The hashcode of a should be different from that of b?
Or is it possible that two different objects can have same hashcode?
 
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you're basing your assumption on the Object.hashCode() behavior: "As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)"

There are many classes that override the Object.hashCode() behavior to adhere to the contract for hashCode() as it relates to equals(). So, as others have already explained, it is entirely possible and logically appropriate that two distinct objects in memory will return the same hashCode() value. Your Integer objects are the perfect example.
 
sathya reddy
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks mate it was really helpful. Thanks.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can find the contract for hashCode() here: https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#hashCode--

Incidentally, Java will cache a relatively small range of Integer values in memory (I think it's -128 to 127) to save some memory and improve performance of auto boxing. This leads to:


Please don't write code that abuses this though. See the danger of doing so if you try to assign a bigger number, like 345, to a and b.
 
Marshal
Posts: 56608
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:. . . Java will cache a relatively small range of Integer values in memory (I think it's -128 to 127) . . .
There are more details in the documentation for Integer#valueOf() and in the Java® Language Specification. Yes, that is the correct default range, but that is a minimum range and can be increased.

No, it isn't quite true that new always creates a separate object: try this code and see what happens:-
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!