3 ms·

It previously wasn't clear that is how substring operated. In fact the Javadoc didn't even mention it. "new string" is rather misleading here. http://docs.orac

It previously wasn't clear that is how substring operated. In fact the Javadoc didn't even mention it. "new string" is rather misleading here. http://docs.oracle.com/javase/6/docs/api/java/lang/String.html#substring%28int%29 http://docs.oracle.com/javase/6/docs/api/java/lang/String.ht... Not documenting it in the Javadoc kind of makes sense since it is an implementation specific detail whether substring returns a view onto the original char array or not. However, it is certainly surprising that what is apparently a 2 character string could be taking up gigabytes of ram. It's the kind of behaviour that it would be useful to express and be able to choose via the API. e.g. make people write .substring(n).view() or .substring(n).copy() or similar.

Someone 13y ago
"new string" is rather misleading here. But the string _is_ new; there was no object that was Object.Equals to it before the call. That new string just never forgets where it came from. e.g. make people write .substring(n).view() or .substring(n).copy() or similar. That's what people have been doing for years: .substring(n) versus new String(substring(n)) (and, as a third option: .substring(n).intern()) I find it weird that this change is made because, as a side-effect, they almost have to start optimizing "new String(s)" calls. With this change, the only thing that can be useful for is for creating a String that is the same as another String, but not equal to it. I think that aspect of that call is rarely, if ever, used. If one can proof that it is never used, the next step on this path would be to make that call into a no-op. If one cannot proof it, it still would likely be a good speed up, but it also would be extremely risky.