B.Tech in Computer Science and Enginering, interested in Distributed Systems. Currently working as a Software Development Engineer in Amazon Swaranga is a DZone MVB and is not an employee of DZone and has posted 4 posts at DZone. You can read more from them at their website. View Full User Profile

String Handling in Java

  • submit to reddit
Strings are one of the most heavily used data types in the Java Programming Language. It is no wonder that much thought has gone into the design of the String data type. They are immutable, fast and have almost all the operations that we might need on a daily basis. However not only the data type itself, the internal handling of the String datatype also has received much focus of research. The Java Virtual Machine has a brilliant way of handling and allocating Strings.

Now when we write
String s;
we are just creating a new reference that can refer to a String but no allocation has been done. When we say
String s = "Swaranga";
a new String object is created in the heap whose starting address is passed to s; Now here is the catch : if we further say
String s2 = "Swaranga";
then in most cases s2 will point to the same "Swaranga" object that was pointed to by s; This is so because the compiler knows that once the original "Swaranga" object was created its contents will never change; hence it is safe to assign the same object to s2 also; This saves a lot of memory in the heap.

The same concept is extended when we create sub strings from a String object. Consider this :
String s = "Swaranga";
here a new string object is created and starting location is assigned to s. Now if we write
String s3 = s1.subString(2, 5);
then a new String object is NOT created. Instead s3 is just assigned the address of the third character of "Swaranga". The reason is same : since the compiler knows that "Swaranga" can never be changed hence it is safe to assign a sub string of "Swaranga".

In all of this we must remember that while it is impossible to change the contents of a String object once allocated, it is trivial to change the references though. For instance in the above example we can easily write
s = s3;
this does not change the contents of "Swaranga" but only shifts the reference s from the starting location of "Swaranga" to the starting location of the third character in "Swaranga" which is 'a';

For those programmers coming from the C background the statement
String s = "Swaranga";
can be viewed as being similar to the C statement 
const char * cp = "Swaranga";
or the statement
char const * cp = "Swaranga";

Happy coding!
Published at DZone with permission of Swaranga Sarma, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Joerg Wassmer replied on Wed, 2011/06/29 - 4:13pm

Sorry, but you are wrong.

String s = "Swaranga";
no new object, but a string constant shared in the whole JVM.

String s3 = s.subString(2, 5);
new object (may be backed by the same char array as s)

s = s3:
Nothing is getting shiftet. The value assigned to s becomes the same object reference as that of s3. s == s3 is true.

Andy Jefferson replied on Thu, 2011/06/30 - 7:33am

How come somebody approved this as an "Announcement" ? It is an article, and doesn't "announce" anything at all.

Jonathan Fisher replied on Thu, 2011/06/30 - 11:52am in response to: Joerg Wassmer


Are you sure? I've heard String s = new String("asdF"); doesn't hit the constant pool... but I guess the literal inside the constructor might hit the String pool... hmm. How would we check this?

Joerg Wassmer replied on Thu, 2011/06/30 - 1:31pm in response to: Jonathan Fisher

Yes, 'new String("A")' always is a new object, while the literal inside the parantheses is a shared constant. The literal itself is a string object. But 's = "A"'' is not the same as 's = new String("A")'.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.