On Mon, Feb 22, 2016 at 11:01 PM, Xueming Shen <xueming.s...@oracle.com> wrote:
> From certain perspective it's a kinda of "regression" that the maximum > capacity for a non-latin1 > buffer/builder is reduced by 2 . But arguably it's really an implementation > detail that how big a > StringBuffer/Builder can really go, as the spec and the implementation > don't/can't guarantee > you can really have a buffer/build with a Integer.MAX_VALUE capacity. On > the other hand on > certain system you might be able to have a bigger buffer/builder for latin-1 > only characters, as > it only requires half the space with the compact string implementation. That > said, I was debating > whether or not the constructor (with the capacity parameter) should check > the capacity, with the > assumption that the buffer/builder might be for non-latin1 input. But it > doesn't like the check > will bring in any benefit... I've done much of this kind of work to "get the last 2x of capacity" in collections and jar/zip, and I've always been surprised how popular these changes are. Serious users run into these limits and they REALLY want that last bit of capacity. So I would do the work to avoid the capacity regression here (or alternatively, don't even bother with LATIN1 compression for "temporary" objects like StringBuilder).
