• 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
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Strings comparison

 
Ranch Hand
Posts: 145
4
Hibernate Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Coderanch team,



It' output

true false false
3254818
3254818
3254818
3254818




As per the replace method of char type version implementation, replace method returns same object if both the parameters are same. So, s1, s2 will refer same object. s1==s2 is true as expected.
Replace method of string type, replaceAll methods must return new string object always. When I compare s1, s3 and s1, s4 with == operator , there are returning false. If I print their hashcodes , all hashcodes are same.
I tested with both Java 8 as well Java 11.
Could you please help me with this ?



 
Bartender
Posts: 2348
102
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This got me curious and I checked String's internal implementation of replace:


 
salvin francis
Bartender
Posts: 2348
102
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whereas the other versions of replace used Pattern to do the replacement and would always return a new String. This should explain the behavior above. Note that if you are confused over the hashcode behavior, you can check the oracle documentation on Hashcode:

javadocs wrote:Returns a hash code value for the object. This method is supported for the benefit of hash tables such as those provided by HashMap.
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 hash tables.

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

     
    Narayana Bojja
    Ranch Hand
    Posts: 145
    4
    Hibernate Spring Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for the reply Salvin. I already mentioned reply method of chars type behaviour in the question. I want answer for why s1, s3, s4 hashcodes are same and When I compare with == operator , it is returning false. Why ?
     
    salvin francis
    Bartender
    Posts: 2348
    102
    Google Web Toolkit Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    The hashcode of a String is calculated based on the characters it contains.
    To be more precise, it simply sums each character's ascii value x 31

    Any two strings objects having the same content will always have the same hashcode, this is in consistence with the defination of hashcode as I stated above. Next, the "==" operator checks if two objects are the same. Two or more String objects may or may not be the same even if they contain the same number of characters. You can use the equals() method to check for the equality instead.
     
    Narayana Bojja
    Ranch Hand
    Posts: 145
    4
    Hibernate Spring Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks again Salvin. I agree . Based string class hashcode method implementation, s1, s2, s3, s4 hashcodes can be same. == operator checks hash code values, right ?. Why s1==s3 is false and s1.hashCode() == s3.hashCode() is true in below code .


    Output

    true false false
    3254818
    3254818
    3254818
    3254818
    true
    true


     
    salvin francis
    Bartender
    Posts: 2348
    102
    Google Web Toolkit Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Narayana Bojja wrote:Why s1==s3 is false and s1.hashCode() == s3.hashCode() is true in below code


    Now that's an interesting question, let's take a step back and understand what is really happening here. If you check the defination of hashcode method, it returns an int, which is a primitive data type. The "==" operator will always return true if two primitive data values are exactly the same. i.e.

    However, this works differently with objects. When you compare two objects using "==", then it will return true only if the two objects are exactly the same.

    The behavior is documented here:https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.21.1 and here https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.21.3

    For your reference, here's the documentation for reference equality:

    Java Language Specification wrote:15.21.3. Reference Equality Operators == and !=
    If the operands of an equality operator are both of either reference type or the null type, then the operation is object equality.

    It is a compile-time error if it is impossible to convert the type of either operand to the type of the other by a casting conversion (§5.5). The run-time values of the two operands would necessarily be unequal (ignoring the case where both values are null).

    At run time, the result of == is true if the operand values are both null or both refer to the same object or array; otherwise, the result is false.

    The result of != is false if the operand values are both null or both refer to the same object or array; otherwise, the result is true.

    While == may be used to compare references of type String, such an equality test determines whether or not the two operands refer to the same String object. The result is false if the operands are distinct String objects, even if they contain the same sequence of characters (§3.10.5). The contents of two strings s and t can be tested for equality by the method invocation s.equals(t).

     
    Marshal
    Posts: 65467
    249
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    salvin francis wrote:. . .

    Java Language Specification wrote:15.21.3. Reference Equality Operators . . .

    If only people would learn those operators' correct names, which tell you that they test whether two references are the same, not whether you have two objects with the same state.
     
    Master Rancher
    Posts: 3322
    31
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Yeah, but it's confusing since they look just like Numeric Equality Operators or Boolean Equality Operators.
     
    Marshal
    Posts: 7084
    491
    Mac OS X VI Editor BSD Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    salvin francis wrote:When you compare two objects using "==", then it will return true only if the two objects are exactly the same.


    I want to clarify this one a bit more.

    "exactly the same" depends on the definition one defines for himself. Perhaps more correct would be to say, "==" checks if two reference variables refering to the same memory location in a heap (where those objects reside).

     
    Campbell Ritchie
    Marshal
    Posts: 65467
    249
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Mike Simmons wrote:. . . they look just like Numeric Equality Operators or Boolean Equality Operators.

    In which case people should be taught that the numeric equality operator looks like the same object operator. Not vice versa.
     
    There’s no place like 127.0.0.1. But I'll always remember this tiny ad:
    Enterprise-grade Excel API for Java
    https://products.aspose.com/cells/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!