I read that they point to the same string in the string pool. What is this string pool? Does it have the string references or the string itself.
Why does not this give a compile time error, a precision loss. We are explicitely converting a double to an int. Shouldn't we also explicitely convert the int to a byte.
Joined: Sep 04, 2005
1.Regarding String Pool : The below link will clarify your doubt. String Pool
2. byte b = (int) 12.2;
Here first your typecasting 12.2 to 12 and then assigning it to byte b.So it will not give any compilation error. To know why you have to something about how numbers are stored internally 1 byte = 8 bits.So if you convert 12 into binary value then it doesnot exceed 8 bits.Moreover the left most bit indicates negative number if it has 1 in that place.You can store 0-127 numbers in that 8 bits.If you exceed 127 then it gives compilation error.
Please anyone correct me if I am wrong.
Joined: Dec 03, 2005
2 Vijay Raj:
What will happen if:
String s = "Vijay"; s.concat(" Raj"); System.out.println(s);
Joined: Jul 26, 2005
This will print "Vijay" instead of "Vijay Raj". The concat() method does not modify the string object on which it is involved, as String oblects are immutable
Joined: Oct 10, 2005
I read the journal article. Cleared all the doubts except one.
When do string literals actually get garbage collected?
Joined: Sep 24, 2003
The referred article contains quite a few red herrings. The instance representing a String literal/constant is indeed eligible for garbage collection.
So, only if we explicitely call the garbage collector, the string literals/constants will be garbage collected. Am I right?
I still am not clear with garbage collection in terms of string literals and string constants.
Joined: Jan 30, 2000
Since this is posted in Beginner, a warning to any beginners who read this thread: stuff about the String pool and garbage collection really, really, really does not matter most of the time. You can waste a lot of time trying to understand this, but if you're indeed a beginner, there are many other things that would be more worthwhile to spend time on.
But if you're still here, what the heck...
[Vijay]: So, only if we explicitely call the garbage collector, the string literals/constants will be garbage collected. Am I right?
No. If the String objects referenced by String literals do become eligible for GC, then that can happen whether or not System.gc() is called. Calling System.gc() makes collection considerably more likely, but nothing will happen during gc() that wasn't already possible without gc().
So when exactly is it possible for a String refenced by a literal to be GC'ed? Only if the class that referenced the literal is itself GC'ed. Which in turn is only possible if the class loader that loaded that class is GC'ed. If these two things happen, and there are no additional references to the String, then it's eligible for GC. The intern pool (the one described in the API for String's intern() method) does not prevent GC - it behaves like a weak reference. However the reference held by the Class is a hard reference, as is the reference held by the ClassLoader to each Class it loaded. So you can ignore the intern pool when thinking about GC of strings, but you can't ignore Classes and ClassLoaders.
What this means is that Strings referenced by String literals can be GC'ed, but it's pretty rare - unless either you're intentionally mucking around with different class loaders, or you're in an environment which routinely creates and discards class loaders for you. (Like say, an application server, or some IDEs I believe.) [ December 05, 2005: Message edited by: Jim Yingst ]