RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary
Martin Buchholz
martinrb at google.com
Tue Mar 1 19:40:59 UTC 2016
On Mon, Feb 22, 2016 at 11:01 PM, Xueming Shen <xueming.shen at 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).
More information about the core-libs-dev
mailing list