How many people have been stung by Java substring memory issues?

Question

I recently discovered that the java.lang.String.substring method does not return a new string, but a view of the original string that was substringed. This can have memory implications. For example, if you're reading an ascii file, and parsing tokens in the file using substring and storing the result of substring in memory somewhere -- what you're actually storing in memory is the entire string prior to the substring operation! You can of course solve this by wrapping substring in your own version that returns a new string of the subtring result.

Answer 1

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html

In the java docs, it states that the substring method does return a new string.

Or did I misunderstand the question?

Also, strings are immutable. Here's a SO thread that explains why that is so.

Answer 2

I've been bitten by it once, reading a dictionary file line by line. Each line was very short, but the buffer created by BufferedReader meant that each string was backed by an 80-char array.

That was when I first learned the point of writing:

word = new String(word);

Most of the time it's not a problem though - and of course it can be more efficient than the "take a completely separate copy" approach.

Answer 3

In the year 2000 or 2001, one of the early XML parsers (I can't remember which) suffered from this problem. It took us a while to track down how we were going out of memory by reading about 3 fields out of some early FpML (very big XML documents which describe financial products).

What is really annoying is that if a write

String copy = new String(s);

IntelliJ IDEA warns me that this is redundant! Stupid IDE.