about String a= "hello"; String b= "hello" a==b , in java

Question

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";
}

Answer 1

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:

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

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

Answer 2

On the JVM level, the LDC (load constant) instruction is used to push a string literal onto the stack. For performance reasons, the string literal isn't stored in the code itself; it's stored in the constant pool of the class. The constant pool is a table which appears at the beginning of a class file containing string literals, numeric literals, field and method descriptors, and a few other things. LDC is followed by a byte specifying the string's index in the constant pool. (If one byte is not large enough, the compiler will use LDC_W, which is followed by a 16-bit offset. Hence the limit of 65,536 constants.)

If the same string literal occurs twice in the same class, javac is smart enough to create only one entry in the constant pool. When a class is loaded, the JVM creates actual String objects from the data in the constant pool. LDCs which contain the same offset into the constant pool will thus cause the same String to be pushed onto the stack. Instructions like IF_ACMPEQ (which checks for reference equality as == does) will then recognize the strings as identical.

See the JVMS for more info.

Answer 3

It's an immutable string (unable to be mutated or changed), not an immune one, though I suppose you could argue that it's immune from change :-)

That means you cannot change the underlying string itself, you can only assign a different string to the variable. So:

string a = "Hello";
a = "Goodbye";

doesn't change the memory where "Hello" is stored, it changes a to point to a different memory location where "Goodbye" is stored.

This allows Java to share strings for efficiency. You can even get cases where strings like "deoxyribonucleic acid" and "acid" may share space, where the latter points to a specific location within the former. Again, this is made possible by the immutable nature of such strings.

In any case, == will check to see if the strings refer to the same underlying object, not something that's often useful. If you want to see if the strings are equal, you should be using String.equals() or one of its variations.

Answer 4

It is fairly simple: the compiler will generate a (bytecode) constant for the string "hello" the first time it encounters it. In normal assembler it would be in the .TEXT section.

The subsequent "hello" strings will then point to that same constant, since there is no need to allocate new space or create a new constant. The reason this is so is because strings are immutable and if one is assigned a new value new memory is needed for it anyway.

It will probably not work on input, i.e. if you let a user input "hello" and ==-compare that to the compile-time hello strings you'll likely get false.

Answer 5

As far as a==b goes, it seems the compiler is making the shortcuts and sharing the same string object. When I declare my varuiables as follows, I get a==b is false.

String a = "hello";
String b = "hell";
String temp = "o";
if (new java.util.Random().nextDouble() < 0.5) b += temp;
else b += "o";

If I do String b = "hell"+"o"; I still get a==b as true.