what is string pooling

[manoj_behera1]

hi,
Any one can tellme about what is string pooling and what are the diffeerence between "String" and "StringBuffer".


also what is difference,when we declare.

String s1="hello";
String s1=new String("hello")

[Bnt]

Hi

Unfortunately I can't help you out with String Pooling, but I can answer your other questions.

The difference between
String s1="hello";
String s1=new String("hello")
is:

If there is already a String literal equal to "hello" present in memory it will be referenced by s1 in the first statement String s1 = "hello"; For the second statement, EVEN if there is a String literal in memory equal to "hello" a new object will be created and used in String s1=new String("hello").

The differnece between a String and a StringBuffer:
String are immutable, ie: they cannot be changed once they have been created, StringBuffers are mutable ie: they can be changed once they have been created by using certain method calls.

This happens because when you create a String

String s = new String("string");

The object is stored in memory and referenced by s, now if you say

s = new String("string2");

The original object will NOT be overwritten, instead a new instance of string will be created in memory and referenced by s but the old reference/object will still remain.

If you need to concatenate a large number of strings it is much quicker and less memory intensive to use StringBuffers e.g:

StringBuffer sb = new StringBuffer("");
sb.append("a").append("b").append("c").append("d");
String s = sb.toString();

This equivalent to doing this in Strings

String s = new String("");
s += "a";
s += "b";
s += "c";
s += "d";

but will be much quicker when using StringBuffers. The reason for this is that because Strings are immutable each time you append to your String s += "a"; a new String object needs to be created for s in memory, where the StringBuffer will remain the same object in memory and just append literals to it.

Hope this helps
Byron

[themoffster]

http://www.freshsources.com/Strings.htm
Figure 1 is the closest I could find.
Never heard of String Pooling though.

[cma]

Here's a page with some info about the String literal pool: http://www.javaranch.com/journal/200...Literally.html

[jsubaa]

String s1="hello";
String s1=new String("hello")

for the first statement, it will create an object in heap
and for the second statement, it will create an object in heap as well as create one more object in string pool.

For the 1st statement, if we assign String s1="Hai"; then that "Hai" will overridden the "hello" but for the 2nd statement a new object will be created with "Hai" and "hello" also retain in string pool.

If any other object say, String s2 = new String("hello") means that wont create a new object instead it will reuse the existing "hello" object.

[dlorde]

If any other object say, String s2 = new String("hello") means that wont create a new object instead it will reuse the existing "hello" object.

No, the 'new' keyword always creates a new object.

You can force a new String to reuse a pooled instance:

String s2 = new String("hello").intern();
// or
String s2 = new String("hello");
...
s2.intern();

Having said that, I don't know why you'd want to create a new String in the first place, and if you did, why then replace it with a pooled instance?

The outcome of any serious research can only be to make two questions grow where only one grew before...
T. Veblen

[keang]

Having said that, I don't know why you'd want to create a new String in the first place, and if you did, why then replace it with a pooled instance?

I suppose it would allow you to compare 2 strings using '==' although I can't say I'd recommend doing this other than in the most extreme of circumstances.

[dlorde]

But why deliberately create a new String in the first place?

Good judgment comes from experience; experience comes from bad judgment...
F. Brooks

[keang]

But why deliberately create a new String in the first place?

Maybe so that you've got 2 strings that you can't compare using '=='

[EDIT]I've just noticed this thread was started in 2005. jsubaa please don't answer threads that have expired a long time ago.

[dlorde]

jsubaa please don't answer threads that have expired a long time ago.

And if you must, try to get the answer right...

If you don't think carefully, you might believe that programming is just typing statements in a programming language...
W. Cunningham