With the warm summer months behind us, at least for another four months, I thought I would talk about another type of pool.

String Pools

Before we get into the pool, let's talk about what I remember about String objects in Java and comparing their values. As I recall, the key that was heavily noted at the time — when Java 1.2 was popular — was to never use == when comparing String values. So, instead of doing this:

if (string1 == string2) {
   // do stuff, because they are equal
} else {
   // what the compiler actually ended up doing
}

The equals() method was recommended:

if (string1.equals(string2)) {
   // really do stuff now
} else {
   // only do this when they are not equal values
}

Since that time, I have just gotten used to using .equals()  for String comparisons.

String Literals Vs. String Objects

As one might hope, the Java language has improved since version 1.2. One of the improvements has been the progression of String literals. An example of a String literal is noted below:

 String myString = "This is a string value"; 

By contrast, a String Object can be established using the following pattern:

 String myOtherString = new String("This is a string value"); 

The big difference is that the use of a String literal will check the String pool for a match before creating a new object in heap memory.

Example #1

So, this means the following code:

String myString = "This is a string value";
String notMyString = "This is a string value";

if (myString == notMyString) {
   System.out.println("myString equals notMyString");
} else {
   System.out.println("myString does not equal notMyString");
}

Will return "myString equals notMyString."

Example #2

However, the following code:

String myString = new String("This is a string value");
String notMyString = new String("This is a string value");

if (myString == notMyString) {
   System.out.println("myString equals notMyString");
} else {
   System.out.println("myString does not equal notMyString");
}

Will return " myString does not equal notMyString."

Example #3

But what if we decided to do this?

String myString = new String("This is a string value");
String notMyString = "This is a string value";

if (myString == notMyString) {
   System.out.println("myString equals notMyString");
} else {
   System.out.println("myString does not equal notMyString");
}

Unfortunately, the "myString does not equal notMyString" is returned here because the String object does not use the String pool. However, if I wanted to put the String object into the String pool, I could do so using the intern()  method:

 String stillMyString = myString.intern();

Now, stillMyString == notMyString is a true statement.

Making == Great Again

Now, consider this example:

TestObject.java

package com.test

public class TestObject {
   private String data;

   public TestObject() {}

   public String getData() {
      return this.data;
   }

   public void setData(String data) {
      this.data = data;
   }
}

Main.java

package com.test;

public class Main {
   public static void main(String[] args) {
      TestObject a = new TestObject();
      a.setData("This is a string value");

      TestObject b = new TestObject();
      b.setData("This is a string value");

      if (a.getData() == b.getData()) {
         System.out.println("a.getData() == b.getData()");
      } else {
         System.out.println("a.getData() != b.getData()");
      }
   }
}

When running the main() program, the result will be:

 a.getData() == b.getData()

 As a result, the == was able to be used when comparing two String values, which are part of an object in the same package.

Conclusion

While I think it is cool that I can use == via a String pool, it is great that we are truly making == great again with respect to Java. I am not sure I am going to get away from using .equals() any time soon, since I have been using this approach since Java 1.2.

What are your thoughts?  How often do you employ String literals over String Objects?  How often are you using == over  .equals()?

Have a really great day!