How to confirm( or get the object repesentation of string) if string created in pool or not?

I want to confirm if two String variable created is pointing to the same memory.The way I did it with normal class

Ideone a=new Ideone();
Ideone b=a;

System.out.println(a+" "+b);

Output

Ideone@106d69c Ideone@106d69c

The output produced here is not the exact memory address but it gave hex code which are same and by which I can say that they both are pointing to same memory address or values.

But in case of String

String a="helloworld";
String b="hello";
String c=b+"world";
System.out.println(a+" "+c);

Output

helloworld helloworld

Its the expected output and I know that a,b,c are created in the pool as they are compile-time constants and a and c do not point to same memory .But is there any way I can get the Object representation of string like String@23122 as to get the hex code of that object to confirm that a and c do not point to same memory? Because in case creating string by new String("helloworld") new memory is allocated to string.

I have searched it but dint find anything similar to my problem.

Thanks in advance.

Solution

As explained in the JLS

A string literal always refers to the same instance of class String.

But also, it depends on how you form the String object too.
Example: Calling new String("abcd") is like having string parameter "abcd" already, but still you force JVM to create a new String reference. Check More Info section...

As you said in your example, you cannot get the pointer id, but still you are able to get some unique string by calling toString() method, using that it kind of conforms they are unique. But the implementation of that toString is Object.toString()

public String toString() {
    return getClass().getName() + "@" + Integer.toHexString(hashCode());
}

So, it is HashCode.

As per the Hashcode contract, if two objects are equal, then that means their hashCode must be same, but it is not true vice versa.

The general contract of hashCode from spec is :

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.

So, either use == operator which will make identity/reference check or you must trust the JVM implementation that the String literals always point to unique reference, else the JVM is not following the specs.

More Info:

This is the example given in above mentioned JLS spec.

package testPackage;
class Test {
    public static void main(String[] args) {
        String hello = "Hello", lo = "lo";
        System.out.print((hello == "Hello") + " ");
        System.out.print((Other.hello == hello) + " ");
        System.out.print((other.Other.hello == hello) + " ");
        System.out.print((hello == ("Hel"+"lo")) + " ");
        System.out.print((hello == ("Hel"+lo)) + " ");
        System.out.println(hello == ("Hel"+lo).intern());
    }
}

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

and the compilation unit:

package other;
public class Other { public static String hello = "Hello"; }

produces the output:

true true true true false true

This example illustrates six points:

Literal strings within the same class in the same package represent references to the same String object.
Literal strings within different classes in the same package represent references to the same String object.
Literal strings within different classes in different packages likewise represent references to the same String object.
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 result of explicitly interning a computed string is the same string as any pre-existing literal string with the same contents.