On Sep 6, 2016, at 2:18 PM, Tim Ellison wrote:
>
> People stash all sorts of things in (immutable) Strings. Reducing the
> limits in JDK9 seems like a regression. Was there any consideration to
> using the older Java 8 StringCoding APIs for UTF-16 strings (already
>
On 9/6/16, 2:18 PM, Tim Ellison wrote:
Do we have a real use case that impacted by this change?
People stash all sorts of things in (immutable) Strings. Reducing the
limits in JDK9 seems like a regression. Was there any consideration to
using the older Java 8 StringCoding APIs for UTF-16
On 06/09/16 19:04, Xueming Shen wrote:
> On 9/6/16, 10:09 AM, Tim Ellison wrote:
>> Has it been noted that while JEP 254 reduces the space occupied by one
>> byte per character strings, moving from a char[] to byte[]
>> representation universally means that the maximum length of a UTF-16
>> (two
On 9/6/16, 12:58 PM, Charles Oliver Nutter wrote:
On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen > wrote:
Yes, it's a known "limit" given the nature of the approach. It is
not considered
to be an "incompatible change", because
On Sep 6, 2016, at 12:58 PM, Charles Oliver Nutter wrote:
>
> On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen
> wrote:
>
>> Yes, it's a known "limit" given the nature of the approach. It is not
>> considered
>> to be an "incompatible change", because
On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen
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
On 9/6/16, 10:09 AM, Tim Ellison wrote:
Has it been noted that while JEP 254 reduces the space occupied by one
byte per character strings, moving from a char[] to byte[]
representation universally means that the maximum length of a UTF-16
(two bytes per char) string is now halved?
Hi Tim,
Yes,