Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java's character and assorted string classes support text-processing

Explore Character, String, StringBuffer, and StringTokenizer

  • Print
  • Feedback

Page 6 of 10

String s3 = new String ("123");


That fragment passes a reference to a string literal-based String containing 123 to the String(String original) constructor. That constructor copies original's contents to the new s3-referenced String.

No matter how many times the same string literal appears in source code, the compiler ensures that only one copy stores in the class file's constant pool. Furthermore, the compiler ensures that only nonduplicates of all string constant expressions (such as "a" + 3) end up in the constant pool as string literals. When a classloader creates Strings from all string literal entries in the constant pool, each String's contents are unique. The classloader interns, or confines, those Strings in a common string memory pool located in JVM-managed memory.

At runtime, as new Strings are created, they do not intern in the common string memory pool for performance reasons. Verifying a String's nonexistence in that pool eats up time, especially if many Strings already exist. However, thanks to a String method, code can intern newly created String objects into the pool, which I'll show you how to accomplish later in this article.

For proof that string literal-based Strings store in the common string memory pool and new Strings do not, consider the following code fragment:

  • Print
  • Feedback

Resources