Why the output is different between JDK 1.4 and 1.

问题:

I'm running this code with JDK 1.4 and 1.5 and get different results. Why is it the case?

String str = "";
int test = 3;

str = String.valueOf(test);
System.out.println("str[" + str + "]\nequals result[" + (str == "3") + "]");

if (str == "3") {
    System.out.println("if");
} else {
    System.out.println("else");
}

outputs:

• on jdk 1.4

  str[3]
  equals result[true]
  if
  

• on jdk 1.5

  str[3]
  equals result[false]
  else
  

回答1:

According to this page, the Integer#toString method (which is called by String#valueOf(int)) is implemented like this in 1.4:

public static String toString(int i) {  
    switch(i) {  
        case Integer.MIN_VALUE: return "-2147483648";  
        case -3: return "-3";  
        case -2: return "-2";  
        case -1: return "-1";  
        case 0: return "0";  
        case 1: return "1";  
        case 2: return "2";  
        case 3: return "3";  
        case 4: return "4";  
        case 5: return "5";  
        case 6: return "6";  
        case 7: return "7";  
        case 8: return "8";  
        case 9: return "9";  
        case 10: return "10";  
    }  
    char[] buf = (char[])(perThreadBuffer.get());  
    int charPos = getChars(i, buf);  
    return new String(buf, charPos, 12 - charPos);  
}

That would explain your result because the string literal "3" is interned and "3" == "3" always returns true.

You can try with 10 and 11 to verify this.

Note: as already mentioned, the javadoc of Integer#toString does not say whether the returned string will be interned or not so both outputs in your question are equally valid.

回答2:

This is an implementation detail that is not specified by the JLS.

The reference equality operator == checks to see whether two variables point to the same actual object, whereas the equals method checks to see whether two variables' values are "equal" in some way that may be determined by the programmer. In this case, it appears that the 1.4 JVM is taking advantage of the fact that Strings are immutable to reuse the same copy of the string "3" when you call valueOf and the 1.5 JVM is not. Both options are perfectly legal, and you should not depend on any particular such behavior.

回答3:

From java 5 string.valueof() is expected to return new string. rather than intern(ed) (shared) string!

Consider following example

    int test = 3;
    String str = String.valueOf(test);
    String str2 = String.valueOf(test);

    if(str == str2)
        System.out.println("valueOf return interned string");
    else
        System.out.println("valueOf does not return interned string");

Output in java >=5

valueOf does not return interned string

But in java 4 output is

valueOf return interned string

That explains the behavior!

回答4:

If you are using "==" operator on operation of String literals, then it depends on the whether the string literal value is present on "String Pool" or not, in your case variable "str" is a string JVM first checks on "String Pool" if it is found then it returns TRUE else FALSE. Try the following code with the intern() method, to make the string literal available on "String Pool"

 String str = "";
 int test = 3;

 str = String.valueOf(test).intern();

 System.out.println("str[" + str + "]\nequals result[" + (str == "3") + "]");

 if (str == "3") {
     System.out.println("if");
 } else {
     System.out.println("else");
 }

according to documentation for intern() method: intern() method searches an internal table of strings for a string equal to this String. If the string is not in the table, it is added. Answers the string contained in the table which is equal to this String. The same string object is always answered for strings which are equal.

Well "==" operation is not recommended for string comparison. use equals() or equalsIgnoreCase() method().

I tried even in java 1.7 without intern() the output is

str[3]
equals result[false]
else

with intern() the output comes to:

str[3]
equals result[true]
if

This is not the problem of jdk 1.4 and 1.5 this is a "logical error".