String and StringBuffer

[Vijay Kumar Agarwal]

Hi All,

We can do all our required activities using StringBuffer.

Then why do we need String Class?

Thanks,
Vijay

[Taariq San]

Originally posted by Vijay Kumar Agarwal:
Hi All,

We can do all our required activities using StringBuffer.

Then why do we need String Class?

Thanks,
Vijay

Many differences, but the main one is that StringBuffer can be modified while String cannot.
StringBuffer is overkill for most purposes, do not replace all your Strings with StringBuffers.

[Maneesh Godbole]

For some reason you do not want to use String, go for StringBuilder instead of StringBuffer to cut down on synchronization overheads.

[Vijay Kumar Agarwal]

Yes i agree that String is immutable so in such case String can be used when we want to assure that vales doesnt get changed. But we can do the same by putting some restrictions on StringBuffer.

But still can you give me some other reason why String is preferable over StringBuffer?

Thanks

[Jesper de Jong]

Because String is immutable, the Java compiler can do certain optimizations with it.

For example, if you create multiple strings with the same (compile-time constant) value, then the compiler will create only one String object, and make both variables refer to that one String object. This saves memory. This optimization wouldn't be possible if strings would be mutable.

[Maneesh Godbole]

Originally posted by Vijay Kumar Agarwal:

But still can you give me some other reason why String is preferable over StringBuffer?

What is the point in re-inventing the wheel? It makes more sense to use what already exists doesn't it?

[Taariq San]

Originally posted by Vijay Kumar Agarwal:
Yes i agree that String is immutable so in such case String can be used when we want to assure that vales doesnt get changed. But we can do the same by putting some restrictions on StringBuffer.

But still can you give me some other reason why String is preferable over StringBuffer?

Thanks

Performance is much better with String.

String is pooled so that if you have the word or letter or sequence "the" in the pool it will use that String instead of making a new one, like StringBuffer would.
String doesn't have all the bells and whistles that StringBuffer does, which is a feature.

[Jelle Klap]

Originally posted by Maneesh Godbole:
For some reason you do not want to use String, go for StringBuilder instead of StringBuffer to cut down on synchronization overheads.

Shouldn't lock elision take care of that regardless?

[Maneesh Godbole]

Originally posted by Jelle Klap:


Shouldn't lock elision take care of that regardless?

I'm sorry. I didn't understand what "lock elision" means.

[Jelle Klap]

Originally posted by Maneesh Godbole:


I'm sorry. I didn't understand what "lock elision" means.

This page explains the concept nicely.

So, for instance, if you keep a StringBuffer reference method local it should be a perfect candidate for lock elision, and essentially be no more costly than StringBuilder would be in terms of synchronization overhead.
[ November 19, 2008: Message edited by: Jelle Klap ]

[Maneesh Godbole]

Originally posted by Jelle Klap:

This page explains the concept nicely.

Thank you for the link. I learnt something new today.
Looks like you might have a point.

[Jelle Klap]

Originally posted by Maneesh Godbole:


Thank you for the link. I learnt something new today.
Looks like you might have a point.

Well, only in specific circumstances and using a very recent JVM
I'm not even sure if Java 6 client VM's even implement these optimizations yet. I'm sure the Hotspot server VM does though.