-2

For == operation on variables of String for two different objects s and p created using new gives result as false (line 1) which I understand but why does line 3 and 4 ( line number commented ) gives true as Output?

I am aware of the fact that == is meant for reference comparison and that's where i have the doubt if it's meant for reference comparison then why line 4 gives true as j is an integer and there is no immutability concept as for String ( String s ) and everytime a new object has to be created ?

    class World
{
    public static void main(String[] args)
    {   
        String s=new String("B");
        String p=new String("B");
        System.out.println(s==p);                    //false    line 1
        Test t1= new Test("A",4);
        Test t2= new Test("A",4);
        System.out.println(t1==t2);                 //false     line 2
        System.out.println(t1.s==t2.s);             //true      line 3
        System.out.println(t1.j==t2.j);             //true      line 4
    }
}

class Test
{
    String s;
    int j;
    Test(String s, int j)
    {
    this.s=s;
    this.j=j;
    }
}
springcloudlearner
  • 457
  • 3
  • 20
  • 4
    "*why line 3 and line 4 gives true as t1 and t2 are different objects*" -- `t1` and `t2` are different objects, but you aren't comparing them in line 3. You are comparing the strings they hold, which are not different objects. You've got two references to the same string literal `"A"`, which is very different than what you did with `s` and `p` where you explicitly created new `String` objects. – azurefrog Oct 14 '17 at 19:58

2 Answers2

1

In Java using the == operator on two integers compares them by value. Meanwhile using == on two strings or your two classes compares their location in memory, not their value. You need to be careful in the Test class because you’re naming your class fields the same thing as your arguments so you might not actually be assigning values of j and s to what you think you are. Try changing your constructor to 

Test(String str, int i){
    s = str;
    j = i;
}
Hallsville3
  • 487
  • 3
  • 7
  • since he uses this for the assignment, there is no need to change the names. And it has nothing to do with the problem. – juwil Nov 15 '17 at 08:51
1

strings are normally cached in java, so two strings with the same value might have the same reference. (The same goes for Integers, there objects in a certain range are referenced as the same object, if they have the same value). This could lead to having the same object "A" as your value of s for t1 and t2 in the constructors. Two int primitives are always the same if they have the same value.

juwil
  • 422
  • 3
  • 9
  • Can you please explain this statement "The same goes for Integers, there objects in a certain range are referenced as the same object, if they have the same value" As per my knowledge this happens only in case of Autoboxing – springcloudlearner Nov 10 '17 at 11:03
  • If you have two small Integers: Integer i1 = Integer.valueOf(127); Integer i2 = Integer.valueOf(127); comparsion will result in i1 == i2. If you instead have two Integers from outside of the caching region, i.e. Integer i1 = Integer.valueOf(1270); Integer i2 = Integer.valueOf(1270); then comparsion will result in i1 != i2. You can easiliy validate this with a simple unit test. Or see the spec at: https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#valueOf(int) – juwil Nov 13 '17 at 10:16
  • this holds true in case of Autoboxing which internally uses valueOf() method as mentioned by you but in the above example neither of the two is happening. – springcloudlearner Nov 14 '17 at 15:45
  • I wrote the part with the Integer as an example (the same goes for Integers..), that values which are cached in java might lead to unexpected results for the == operator. And as I wrote in my above clarification, Integers are cached in java (independent of Autoboxing and not restricted to valueOf by any contract) like strings. The explanation from azurefrog is about comparing strings, which may be the same object, not just having the same value ("A" in that case). I wanted to make clear, that even apparently different objects may own the same reference, if they have the same value. – juwil Nov 15 '17 at 08:48