Thread: Comparison of Objects and such

Going off of GregBrannon's comment: consider that String is an object, not a primitive (like an int, for example).

--- Update ---

Originally Posted by hs82

String1 and String2 both are reffering same data in String pool.

So String1 == String2 will be TRUE (As both variables referring same data)

And String1.equals(String2) will be TRUE (As both variables have same contents)

Wrong. String1 == String2 is FALSE

hs82, are you asking me to run that code or the OP?

Originally Posted by hs82

Yes.. Because I have tested this using above code.

Oh, that's an interesting compiler trick. Apparently the compiler combines literal Strings in an optimization attempt.
Now try these two examples which, while in spirit are the same, break the compiler's optimization trick:

public class StringMatch {
 
public static void main(String[] args) {
String s1 = "TEST";
String s2 = "TE";
s2 = s2+"ST";
if(s1 == s2){
System.out.println("MATCHED");
}else{
System.out.println("NOT MATCHED");
}
if(s1.equals(s2)){
System.out.println("MATCHED");
}else{
System.out.println("NOT MATCHED");
}
}
}

public class StringMatch {
 
public static void main(String[] args) {
String s1 = new String("TEST");
String s2 = new String("TEST");
if(s1 == s2){
System.out.println("MATCHED");
}else{
System.out.println("NOT MATCHED");
}
if(s1.equals(s2)){
System.out.println("MATCHED");
}else{
System.out.println("NOT MATCHED");
}
}
}

== should never be used to compare values of two Strings. String is an object, so == compares reference. Just because the compiler does a little trick to combine literals into the same reference does not mean it is a safe way to compare Strings.

Originally Posted by hs82

I agree that we shall never use == operator to compare two objects.

Can you please explain little more about what you said about Compiler optimization in case of my code. Also will the String pool is going to have two separate string in following case:

String s1 = new String("TEST");
String s2 = new String("TEST");

Thanks for sharing your views.

The difference between:
String s1 = new String("TEST");
String s2 = new String("TEST");

and:
String s1 = "TEST";
String s2 = "TEST";

is that the second one initializes with a literal String, whereas the first one uses the String constructor. When the compiler optimizes, it combines the literal Strings with all the same value into a single reference. It does this to free up, what it sees as, unnecessarily allocated memory. When you initialize the String with the constructor, the compiler does not optimize it, since it is treating it like an Object, instead of a literal String.
At first this would seem like really dangerous optimization because: what if you changed one of the values? Everything you know about changing the values in references would suggest the other String would also change. But this is not the case, since Strings are immutable, meaning their value cannot change. When you reinitialize a String, it does not change the value in the reference that the String was pointing to, it creates a whole new reference and reassigns the String's pointer to the new reference (without changing all the other Strings which reference the old value).
When you create part of the String and then concatenate the rest (like in my first example code a few posts ago). The compiler does not process the concatenation, so it does not recognize the Strings have the same value, despite being initialized with literal Strings.
Using the == to compare literal Strings is relying entirely on compiler optimization and not on the language constraints. There is no guarantee that part of the compiler optimization will exist in future compiler versions, or that it is compatible with previous compiler versions. When coding, you want to stay within the constraints of the language, not within whatever the current compiler will allow you to get away with.

Originally Posted by aussiemcgr

Apparently the compiler combines literal Strings in an optimization attempt.

Nothing to do with optimisation and everything to do with the String Literal Pool.

Originally Posted by hs82

Thanks you so much, for such a clear and logical explanation.

String s1 = new String("TEST");
String s2 = new String("TEST");

In this case two Objects are created, with pointing to same string in String pool (Please correct me if I am misinterpreting your above answer)

So if I do :

s1 = new String("NEW");

Then , in String pool, a new literal will be created "NEW".

Also, what should be the ideal way to use Strings. Initializing with literal or using new String(" ") if we consider:
1) Performance / optimization
2) Security

Thanks in advance.

If you do a == on s1 and s2, you will get FALSE. They are not the same object.
Literals are usually used to initialize Strings, but it is more of a convention than a requirement. As I said earlier, since Strings are immutable, there is not the concern of altering the values for other Strings when changing the value of one.

what is the best way

If you are talking about having the compiler generate the fewest lines of code, write a small program with the different techniques, compile it and use the javap command to write out the generated code so you can see what is generated.

Originally Posted by hs82

I agree that == should never be used for comparing two objects.

For this particular case or in any case == should never be used.

But I want to know what is the best way to create String variables in general:
1) Using String str = "ABC";
or
2) Using String str = new String("ABC");

As per concept of String pooling, we should use first method. What is your opinion on this.

== does have a use: when you want to see if two objects are the same physical reference. For example, the java.util.EventObject class is used in GUIs for event handling. This object has a getSource() method, which returns the object which is the event's source. If you have a handful of JButtons, and you don't know which one was the source, it is very common to check each one against the getSource() method using ==. Another example is comparing Enums, although those are often done in switch statements.
But in the case of Strings, == can be deceiving due to the literal pool.

Most people advise using literals to initiate Strings. There are apparently advantages to using the construct for programs which require synchronization, but I've never personally ran into any issues here.
The constructor is needed if you want to a unique String value which is not referring to the literal String pool. Some people have mentioned this in the String.substring() method, since apparently all that does is adjust the starting index value in the String object, so all the characters which you thought you got rid of with the substring method apparently still exist in the String object. But it is debatable whether or not this even matters.
But these are very odd examples. In 99.99% of java programming you'll do, initializing with literals should be fine.