Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
The answer is 0. String literals are not garbage collected. However if the code was written like this.... String string1 = new String("Test"); String string2 = new String("Today"); string1 = null; string1 = string2; The answer would be 1.
I have to agree with Jimmy. The J2SE API spec for the String.intern() method states "A pool of strings, initially empty, is maintained privately by the class String." Additionally, "All literal strings and string-valued constant expressions are interned," i.e. they are added to the String pool. This implies that the String class manages "Test" and "Today" within its private String literal pool. Hence, even if "Test" is no longer referenced, the pool manager may still be holding on to it, thereby preventing the garbage collector from freeing the object from memory.
The pool of strings kept by the class String is not the cause that string literals are not g.ced The string objects computed from compile-constant expressions (JLS15.28) may reside on such pool(*); but, they are pointed to by the constant pool of the class declaring the string literals. Thus only downloading (from the JVM) the class where the string literals were declared, it is possible to make them eligible for g.c. Fortunately this is not a subject for the exam. (*) I am not saying that literals string objects reside in such a pool. This pool could be just a set of references pointing to the real objects. I do not really know about it. I can only say that objects are in the heap. [ March 01, 2003: Message edited by: Jose Botella ]
SCJP2. Please Indent your code using UBB Code
Straws are for suckers. Now suck on this tiny ad!
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth