3 ms·
> some risk-averse Java-powered companies out there There millions of them. But if anything I would expect that risk aversion to translate into not back portin
by zmmmmm 6y ago
> some risk-averse Java-powered companies out there
There millions of them. But if anything I would expect that risk aversion to translate into not back porting discretionary performance fixes. For example, the fix I linked to improves BufferedReader performance by swapping a thread-safe underlying class for a non-thread-safe version. That could introduce race conditions and other synchronization issues into its behavior. Thread safety was never specified in the API so that's fine for prospective versions, but having this land unexpectedly in a minor version update bundled with security patches .... is almost the opposite of what I would want.
- MaxBarraclough 6y agoWell spotted. Surprised no-one even mentioned this in the comments there.
- NovaX 6y agoIt is a method-scoped variable that is operated on under the reader's lock. Therefore the additional locking by StringBuffer is unnecessary and there is no negative impact by switching to StringBuilder.
- zmmmmm 6y agoYou're right - it makes me feel a bit better. But the underlying point ... that I'm surprised this sort of thing is getting backported, I think is still the same.