31

The behavior of String literals is very confusing in the code below.

I can understand line 1, line 2, and line 3 are true, but why is line 4 false?

When I print the hashcode of both they are the same.

class Hello
{
   public static void main(String[] args)
   {
      String hello = "Hello", lo = "lo";
      System.out.print((Other1.hello == hello) + " ");     //line 1
      System.out.print((Other1.hello == "Hello") + " ");   //line 2
      System.out.print((hello == ("Hel"+"lo")) + " ");       //line 3
      System.out.print((hello == ("Hel"+lo)) + " ");         //line 4
      System.out.println(hello == ("Hel"+lo).intern());      //line 5
      System.out.println(("Hel"+lo).hashCode());   //hashcode is 69609650 (machine depedent)
      System.out.println("Hello".hashCode());       //hashcode is same WHY ??.
   }
}

class Other1 { static String hello = "Hello"; }

I know that == checks for reference equality and check in the pool for literals. I know equals() is the right way. I want to understand the concept.

I already checked this question, but it doesn't explain clearly.

I would appreciate a complete explanation.

Community
  • 1
  • 1

11 Answers11

26

Every compile-time constant expression that is of type String will be put into the String pool.

Essentially that means: if the compiler can (easily) "calculate" the value of the String without running the program, then it will be put into the pool (the rules are slightly more complicated than that and have a few corner cases, see the link above for all the details).

That's true for all the Strings in lines 1-3.

"Hel"+lo is not a compile-time constant expression, because lo is a non-constant variable.

The hash codes are the same, because the hashCode of a String depends only on its content. That's required by the contract of equals() and hashCode().

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
  • ok i want to clearify one more thing , if we do like "Hello" in program or in if condition , thats a new object or literal ?? –  May 24 '13 at 07:02
  • 1
    A literal such as `"Hello"` is always a compile-time constant expression, therefore this will be taken from the constant pool. – Joachim Sauer May 24 '13 at 07:06
  • ok that is fine , let say if the question is how many objects are formed , then , i do if(hello=="Hello") , so when i type "Hello" its not a object and a compile time literal and kept in pool , right ? –  May 24 '13 at 07:09
  • "how many objects are formed" is ... a pretty ill-defined question, and frankly only ever interesting to a teacher ;-) Strings in the constant pool are also objects and they also get created at *some* point. Should you count them or not? I don't know. – Joachim Sauer May 24 '13 at 07:10
  • well then i dont how you work , because to make a good performance application you should know how many objects are created at runtime , i use profiler in eclipse , but i want to know how we can count it in compile time as Oracle asks in OCPJP certification ,they want us to know that !! anyway THANKS , ur ans is great and easy to understand –  May 24 '13 at 07:13
  • 3
    No, to make a good performance application you *measure* what slows it down and optimize *that*. I've done that a few times, and I the question if a `String` is a constant or not never was part of the performance problem. Creating too many `String` objects by concatenating in a loop *could easily* be the problem, but that's not (IMHO) related to this question. – Joachim Sauer May 24 '13 at 07:15
  • correct for that we need to understand the concept that when it is going to make it an object and constant !! , so if the question is how many objects are created , i am not saying that how many objects are really made in RAM , its not possible for us to know it exactly , but i meant that how we can know that "Hello" is a constant literal or object will be created for that , String s=new String("Hello"); is surely an object , so "Hello" is an object created but at compile time it takes it as constant , does it assumes it as object at compile time –  May 24 '13 at 07:19
  • Do you count one String as one or as two (String itself and its char[])? – Alpedar May 24 '13 at 09:01
  • How about making `lo` final. – Alvin Wong May 24 '13 at 12:57
  • @AlvinWong ok lets try that –  May 24 '13 at 13:41
2

Strings computed by concatenation at runtime are newly created and therefore distinct

here is a link to read: http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.5

Chechulin
  • 2,426
  • 7
  • 28
  • 35
  • who downvoted this comment , i think this is right , @JoachimSauer you please check !! –  May 24 '13 at 06:56
2

String object can be created in the following ways:

String str = new String("abcd");  // Using the new operator 
                                  // str is assigned with "abcd" value at compile time.

String str="abcd";         // Using string literal
                           // str is assigned with "abcd" value at compile time.

String str="ab" + "cd";    // Using string constant expression.
                           // str is assigned with "abcd" value at compile time.
String str1 = "cd";
String str = "ab"+str1;    // Using string expression.
                           // str is assigned with "abcd" value at run time only.

and Hashcode will be calculated only at runtime based on the contents of the String objects.

Karthi
  • 1,161
  • 1
  • 9
  • 11
1

It's because the comipler in this instance is not smart enough to work out that it can burn in the same string literal.

Hashcode needs to always return the same value for strings that are equivelent (calling .equals on it returns true) so will return the same result.

Tom
  • 43,583
  • 4
  • 41
  • 61
  • stackoverflow.com/questions/3029244/are-strings-created-with-concatenation-stored-in-the-string-pool same is written here – ManMohan Vyas May 24 '13 at 07:00
0

As you already know ... this is just because of reference ...when string comes from the pool it will have same refrence ...but when u do manuplations a new string with new refrence is generated ...

You can check this link for pooling concept

Community
  • 1
  • 1
ManMohan Vyas
  • 4,004
  • 4
  • 27
  • 40
  • 2
    then how does it apply for hello == ("Hel"+"lo") --> true? – sanbhat May 24 '13 at 06:47
  • Could you please go more in-depth. I'm not sure you are correct – Craig May 24 '13 at 06:48
  • ok in line3 i am doing manipulation "Hel"+"lo" will create new object but it still referred to "Hello" String in pool and when "Hel"+ lo , lo is string variable is added , it will create "Hello" then why this is not referred to same pool literal ?? –  May 24 '13 at 06:48
  • @sanbhat +1 to your comment – Saurabh May 24 '13 at 06:53
0

Its because following code 

("Hel"+lo)) + " "

is translated internally to

new StringBuilder("Helo").append(new String(lo)).append(new String(" ")).toString()

So you can see that entirely a new String instance is created with help of different String instances. That is why you get false as they point to different memory locations in heap

Saurabh
  • 7,894
  • 2
  • 23
  • 31
0

The hashCode doesn't have anything to do with an objects reference (The == check is a reference comparator). Its possible to have 2 objects where the hashCode returns the same value, the equals operator returns true, but == returns false. This is when they are 2 different objects, but with the same value.

I believe the reason line 4 is returning false is that it is a value computed at runtime, and thus is a different string instance, with a different reference.

Ren
  • 3,395
  • 2
  • 27
  • 46
  • hmm quite well , so at compile time it will check in string pool but when it comes to String manipulation with lo , it will check in runtime , then String hello="Hello" should also be checked at runtime , right ?? –  May 24 '13 at 06:54
  • String hello="Hello" will be done at compile time, because the compiler knows, before any code is executed, the value ("Hello") that needs to go into that string. – Ren May 24 '13 at 06:57
0

String literals are saved in a special memory, if they are exactly the same, they are pointed to the same map of memory. If you don't create a literal String, a new object will be created so it won't point to that memory so the reference won't be the same.

The intern() method tells the virtual machine to put it into that shared, string literals map of memory so next time you do that literal, it'll search there and point it.

Javier Diaz
  • 1,791
  • 1
  • 17
  • 25
0

The difference between line number 3 and 4 are as follows.

•Strings computed by constant expressions are computed at compile time and then treated as if they were literals.

•Strings computed by concatenation at run time are newly created and therefore distinct.

The above reference is taken from java spec. Please let me know if you need more clarification.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.5

dinezhr
  • 11
  • 5
0

Finally I know the answer !

Read Java SE 8 specification section 15.21.3 Reference Equality Operators == and != (http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.21.3)

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

So the following code :

class Test {
    public static void main(String[] args) {
        String hello = "Hello";
        String lo = "lo";
        System.out.println((hello == ("Hel"+lo))); // line 3
    }
}

The expression ("Hel"+lo) in line 3, return the new Strings that computed by concatenation at run time.

*Strings computed by concatenation at run time are newly created and therefore distinct. (http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#d5e1634)

So the result of this code:

class Test {
    public static void main(String[] args) {
        String hello = "Hello";
        String lo = "lo";
        System.out.println((hello == ("Hel"+lo))); // line 3
    }
}

would result:

false

Because,

the "Hello" object in this expression:

String hello = "Hello";

and ("Hel"+lo) object in this expression:

System.out.print((hello == ("Hel"+lo)) + " ");

is different, although :

*they both contain the same sequence character, which is "Hello".

*they both have the same hashCode.

*hello.equals(("Hel"+lo)) will return true.

reinardhz
  • 63
  • 6
0

System.identityHashCode() would be returned by the default method hashCode(), this is typically implemented by converting the internal address of the object into an integer.

Sunil Garg
  • 14,608
  • 25
  • 132
  • 189
Monster
  • 1
  • 1