Originally posted by lajos kamocsay: The reason I'm asking is that BufferedReader.readLine() returns Strings. I'm reading lots of data- should I be concerned about filling up the String pool?
There are only two ways for strings to get into this "string pool" you ask about. The first is when you use a string literal -- a "constant" -- in your code, and the compiler puts it there. And the second is to explicitly call the intern() method of a string object.
So unless you're calling the intern() method of the strings that the BufferedReader returns to you, you won't have any effect on the string pool. And all your concerns are baseless.
By the way, where did you get this idea from? This is the second time I've seen people say that this week around here.
Joined: Aug 12, 2006
Thanks for the replies.
I read the following in Kathy Sierra's SCJP 5 book. I missed the "literal" part.
One of the key goals of any good programming language is to make efficient use of memory. As applications grow, it's very common for String literals to occupy large amounts of a program's memory, and there is often a lot of redundancy within the universe of String literals for a program. To make Java more memory efficient, the JVM sets aside a special area of memory called the "String constant pool." When the compiler encounters a String literal, it checks the pool to see if an identical String already exists. If a match is found, the reference to the new literal is directed to the existing String, and no new String literal object is created. (The existing String simply has an additional reference.) Now we can start to see why making String objects immutable is such a good idea. If several reference variables refer to the same String without even knowing it, it would be very bad if any of them could change the String's value.