4 ms·
While you are not wrong about this all being to accommodate for badly written code, I don't think that a programmer should specifically have to adapt there code
by jug6ernaut 13y ago
While you are not wrong about this all being to accommodate for badly written code, I don't think that a programmer should specifically have to adapt there code for something as simple as substring() to accommodate for a flaw in the language implementation(memory leak).
- emn13 13y agoIt's not a flaw - nowhere is it specified that the substring doesn't retain a reference to the original string; nor in any case does the garbage collecter make very many guarantees in the first place. The new behaviour is fine. But it's not a bugfix, and it causes nasty problems - probably causes more problems than it fixes simply because it's a change in behavior. In order to write efficient string-processing algorithms in java, since the docs habitually don't specify efficiency, you need to make assumptions about which operations are how fast. Making an operation this much slower - and it's really a huge difference - is pretty risky. Also, note that memory use in the new model is also likely to be higher, and can even be catastrophically higher (e.g. a recursive descent parser might retain references to all suffixes it builds during descent, causing quadratic memory usage). I'm sure there are good reasons for the change, but the the way it was released is really shoddy - hiding it away in a minor (ideally just bugfix+security) release without a good warning well in advance means they didn't consider this to be breaking change, and that's just being ridiculously naive for a project as mature as the JVM.