DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Data
  4. String Pools Make == Great Again

String Pools Make == Great Again

Learn more about how == is transforming the way we use String pools.

John Vester user avatar by
John Vester
CORE ·
Jan. 23, 19 · Tutorial
Like (10)
Save
Tweet
Share
11.76K Views

Join the DZone community and get the full member experience.

Join For Free

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!

Strings Data Types

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Remote Debugging Dangers and Pitfalls
  • PHP vs React
  • Fraud Detection With Apache Kafka, KSQL, and Apache Flink
  • Agile Transformation With ChatGPT or McBoston?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: