check the following program:
Run it in sun java hostspot jvm, everything will be “true”.
——–updated: got the answer by Stephen and Danie,changed the program to add string intern method———–
how it will become, if B is separate compiled not together with A, what will happen???, for example , B is compiled and put in a jar, and put its class path when run TestStringEqual ??
Also, is this java compile time optimization, or java run time optimization, or java language specification defined ??
Also, it this program comes the same result on different VMs, or just one VM feature?
thanks
public class TestStringEqual {
public static String HELLO = "hello";
private String m_hello;
public TestStringEqual() {
m_hello = "hello";
}
public static void main(String[] args) {
String a = "hello";
String b = "hello";
System.out.println("string a== string b:" + (a == b));
System.out.println("static memebr ==a:" + (HELLO == a));
System.out.println("instance field ==a:"
+ (new TestStringEqual().getHello() == a));
System.out.println("hello in B ==a:" + (B.B_HELLO == a));
System.out.println("interned new string object in heep==a:"
+ ( new String("hello").intern() == a));
}
public String getHello() {
return this.m_hello;
}
}
class B{
public static final String B_HELLO = "he"+"llo";
}
There is really no mystery about this at all. You just need to know three basic facts about Java:
The ‘==’ operator for object references tests if two object references are the same; i.e if they point to the same object. Reference JLS 15.21.3
All String literals with the same sequence of characters in a Java program will be represented by the same String object. Reference JLS 3.10.5 So (for example)
"hello" == "hello"is comparing the same object.Constant expressions are evaluated at compile time. Reference JLS 15.28. So (for example)
"hell" + "o"is evaluated at compile time, and is therefore equivalent to the literal"hello".These three facts are stated in the Java Language Specifications. They are sufficient to explain the “puzzling” aspects behaviour of your program, without relying on anything else.
The more detailed explanation involving the string pool, string literals being interned by the class loader, the bytecodes emitted by the compiler, etc, etc … are just implementation details. You don’t need to understand these details if you understand what the JLS is saying, and they don’t really help to make the JLS clearer (IMO).
Notes:
The definition of what is and what isn’t a constant expression is a little involved. Some things that you might imagine to be constant valued, are in fact not. For instance,
"hello".length()is not a constant expression. However, a concatenation of two string literals is a constant expression.The explanation of equality of string literals in the JLS does in fact mention interning as the mechanism by which this property of literals is implemented.