JEP 254: Compact Strings - length limits
xueming.shen at oracle.com
Tue Sep 6 21:12:08 UTC 2016
On 9/6/16, 12:58 PM, Charles Oliver Nutter wrote:
> On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen <xueming.shen at oracle.com
> <mailto:xueming.shen at oracle.com>> wrote:
> Yes, it's a known "limit" given the nature of the approach. It is
> not considered
> to be an "incompatible change", because the max length the String
> class and
> the corresponding buffer/builder classes can support is really an
> details, not a spec requirement. The conclusion from the
> discussion back then
> was this is something we can trade off for the benefits we gain
> from the approach.
> Do we have a real use case that impacted by this change?
> Well, doesn't this mean that any code out there consuming String data
> that's longer than Integer.MAX_VALUE / 2 will suddenly start failing
> on OpenJDK 9?
Yes, true. But arguably the code that uses huge length of String should have
fallback code to handle the potential OOM exception, when the vm can't
the size, as there is really no guarantee the vm can handle the >
length of String.
> Not that such a case is a particularly good pattern, but I'm sure
> there's code out there doing it. On JRuby we routinely get bug reports
> complaining that we can't support strings larger than 2GB (and we have
> used byte for strings since 2006).
That was a trade-off decision to make.
Does JRuby have any better solution for such complain? ever consider to
go back to use char
to "fix" the problem? or some workaround such as to add another byte
btw, the single byte only string should work just fine :-) or :-(
depends on the character set
More information about the core-libs-dev