Hacker News Reader

Comment by midko | Hacker News Reader

The article is an example of using an anecdote ("During our course, the customer remarked that they had a real issue with this new Java 7 and 8 approach to substrings") and a skewed microbenchmark to extrapolate to general advice.

The substring change was done to address common real scenarios, as the author of the change described here: http://www.reddit.com/r/programming/comments/1qw73v/til_orac...

View on HN

It does address common real scenarios. However, it also causes issues for other common real scenarios. For instance, say you have a CSV parser where you generally only look at a few columns. Under the old system, it wasn't crazy to implement this by, for each field, checking if any unescaping is necessary, and if not (generally the common case) doing a substring. This produces some garbage, of course, but manageable amounts. This approach abruptly gets _far_ slower under Java 7.

I can see why they made the change, but it absolutely did cause problems for real-world use-cases.

The way the change was distributed (in a bugfix release) and (mis)communicated was completely wrong, I definitely agree with that. As for the parsing example, yes, that's one way to implement this but definitely not the only right one -- if you care only about a couple of fields from a massive string, it depends on your application domain whether you can tolerate the additional memory bloat. What I like about the current behaviour is that the method is less surprising and more GC friendly

Oh, there are definitely other approaches to the problem I mentioned (and in fact approaches which are better than the naive split even under Java 6). Changing it out from under people should have been done a lot more carefully, though.

Reply on news.ycombinator.com