string question

[Rauhl Roy]

what is the difference between

// 1/
String a="how";
a=a+"are";
a=a+"you";

System.out.println(a);

And

// 2/

String a="how";
String b="are";
String c="you";
String d=a+b+c;
System.out.println(d);

is it same or 1st one performs better then 2nd due to may string declarations? how is it going to impact in big applications?

[Prabhakar Reddy Bokka]

In the first case all the strings created before the last statement are became orphan. Since they are not assigned to any variables they are eligible for Garbage Collection.

In the second case all the strings are pointing to some variables so, they are not eligible for Garbage Collection.

Hope you got the reason why first case is optimum.

[Rauhl Roy]

Prabhakar Bokka wrote:In the first case all the strings created before the last statement are became orphan. Since they are not assigned to any variables they are eligible for Garbage Collection.

In the second case all the strings are pointing to some variables so, they are not eligible for Garbage Collection.

Hope you got the reason why first case is optimum.

not fully clear. can you tell me one more time.

[Prabhakar Reddy Bokka]

In the first case will you be able to access the strings "how" , "are", "you" anywhere in your code after
a=a+"you";
??
So, where they will go? GC?? your memory freed?

In second case you are still be able to access. so they will be in memory.

[Rob Spoor]

With Sun's Java 6 compiler, your two examples will be compiled to these:

// 1)
String a = "how";
a = (new StringBuilder()).append(a).append("are").toString(); // the StringBuilder is eligible for GC now, the old a exist in the string pool
a = (new StringBuilder()).append(a).append("you").toString(); // the StringBuilder and the old a are eligible for GC now

// 2)
String a = "how";
String b = "are";
String c = "you";
String d = (new StringBuilder()).append(a).append(b).append(c).toString(); // the StringBuilder is eligible for GC now

So the second one is slightly better.

[Rauhl Roy]

may i know why second one is better when your making most of the date to GCable through first example.

[Janeice DelVecchio]

Rob -

I like your example.

In the first example, how is the "old a" ever able to be GC?
I was under the impression that string literals hung out in the pool forever..... of course I'm incredibly dense when it comes to GC and strings.....

[Krep Lock]

Janeice DelVecchio wrote:Rob -

I like your example.

In the first example, how is the "old a" ever able to be GC?
I was under the impression that string literals hung out in the pool forever..... of course I'm incredibly dense when it comes to GC and strings.....

String literals safely remain in the pool as long as one or more reference is pointing at them. So when the reference to "how" is overwritten in a with a reference to "howare" the older String's milliseconds are numbered.

[Rauhl Roy]

String literals safely remain in the pool as long as one or more reference is pointing at them. So when the reference to "how" is overwritten in a with a reference to "howare" the older String's milliseconds are numbered.

kemp may i know the answer to my question?

[Krep Lock]

Rauhl Roy wrote:

kemp may i know the answer to my question?

Q. Which example is better?

A. Example 1, which uses only String a.

Q. Why o why?

A. Example 1 uses less heap memory. By the time you get to the final line of example 1 you have the following string persisting on the heap:

"howareyou"

By the last line of example 2 there are many more strings persisting on the heap:

"how"
"are"
"you"
"howareyou"

All other things being equal, in a "big application" you are likely to tax system resources much quicker using example 2.

[Darryl Burke]

Rauhl Roy wrote:String literals safely remain in the pool as long as one or more reference is pointing at them. So when the reference to "how" is overwritten in a with a reference to "howare" the older String's milliseconds are numbered.

Nope. From http://www.javaranch.com/journal/200409/ScjpTipLine-StringsLiterally.html

Unlike most objects, String literals always have a reference to them from the String Literal Pool. That means that they always have a reference to them and are, therefore, not eligible for garbage collection.

[Jesper de Jong]

Rob is correct.

If you want to find out exactly what the Java compiler does with your source code, you can use the javap tool which is included in the JDK to disassemble your class file. Have a look at the following program, for example:

public class JavaRanch {
	public static String method1() {
		String a = "how";
		a = a + "are";
		a = a + "you";
		return a;
	}

	public static String method2() {
		String a = "how";
		String b = "are";
		String c = "you";
		String d = a + b + c;
		return d;
	}

	public static void main(String[] args) {
		System.out.println(method1());
		System.out.println(method2());
	}
}

You can compile this and then disassemble the class file with the command:

javap -c JavaRanch

You'll get this output:

Compiled from "JavaRanch.java"
public class JavaRanch extends java.lang.Object{
public JavaRanch();
  Code:
   0:	aload_0
   1:	invokespecial	#1; //Method java/lang/Object."<init>":()V
   4:	return

public static java.lang.String method1();
  Code:
   0:	ldc	#2; //String how
   2:	astore_0
   3:	new	#3; //class java/lang/StringBuilder
   6:	dup
   7:	invokespecial	#4; //Method java/lang/StringBuilder."<init>":()V
   10:	aload_0
   11:	invokevirtual	#5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   14:	ldc	#6; //String are
   16:	invokevirtual	#5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   19:	invokevirtual	#7; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   22:	astore_0
   23:	new	#3; //class java/lang/StringBuilder
   26:	dup
   27:	invokespecial	#4; //Method java/lang/StringBuilder."<init>":()V
   30:	aload_0
   31:	invokevirtual	#5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   34:	ldc	#8; //String you
   36:	invokevirtual	#5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   39:	invokevirtual	#7; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   42:	astore_0
   43:	aload_0
   44:	areturn

public static java.lang.String method2();
  Code:
   0:	ldc	#2; //String how
   2:	astore_0
   3:	ldc	#6; //String are
   5:	astore_1
   6:	ldc	#8; //String you
   8:	astore_2
   9:	new	#3; //class java/lang/StringBuilder
   12:	dup
   13:	invokespecial	#4; //Method java/lang/StringBuilder."<init>":()V
   16:	aload_0
   17:	invokevirtual	#5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   20:	aload_1
   21:	invokevirtual	#5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   24:	aload_2
   25:	invokevirtual	#5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   28:	invokevirtual	#7; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   31:	astore_3
   32:	aload_3
   33:	areturn

public static void main(java.lang.String[]);
  Code:
   0:	getstatic	#9; //Field java/lang/System.out:Ljava/io/PrintStream;
   3:	invokestatic	#10; //Method method1:()Ljava/lang/String;
   6:	invokevirtual	#11; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   9:	getstatic	#9; //Field java/lang/System.out:Ljava/io/PrintStream;
   12:	invokestatic	#12; //Method method2:()Ljava/lang/String;
   15:	invokevirtual	#11; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   18:	return

}

It's Java virtual machine assembly language, with comments from which you can see what exactly it's doing.

[Rob Spoor]

Janeice DelVecchio wrote:In the first example, how is the "old a" ever able to be GC?

With "old a" I indeed meant "howare". "how", "are" and "you" still exist in the String pool.

Krep Lock wrote:Q. Which example is better?

A. Example 1, which uses only String a.

Q. Why o why?

A. Example 1 uses less heap memory. By the time you get to the final line of example 1 you have the following string persisting on the heap:

"howareyou"

By the last line of example 2 there are many more strings persisting on the heap:

"how"
"are"
"you"
"howareyou"

The String literals "how", "are" and "you" do not exist on the heap but in the String pool. This is true for both examples. So example one has two Strings ("howare" and "howareyou") on the heap whereas example two only has one ('howareyou"). Not to mention the intermediate StringBuilders - two for example one versus one for example two. In the end, after garbage collection has cleaned up, both only have "howareyou" on the heap. It's the intermediate situation that makes the second example better.

[Campbell Ritchie]

Too difficult for "beginning". Moving thread.

[Prabhakar Reddy Bokka]

I had a question again on this!

Is there any size limit to the "String pool"?

If no limit, isn't it occupy the whole heep? (Thinking there are many strings created in many classes in a large application)

[Ernest Friedman-Hill]

Prabhakar Bokka wrote:
Is there any size limit to the "String pool"?

If no limit, isn't it occupy the whole heep? (Thinking there are many strings created in many classes in a large application)

There's no limit, but it by default holds only Strings that appear as "double quoted literals" in your source code, and it's hard to imagine code that contained so many of those that there was a problem. It holds only one copy of each literal that appears, and in fact, literals will be shared between classes -- so it's actually a means of using less memory, not more.