6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

[naoto.sato at oracle.com]

Hi Philipp,

Sorry for the delay.

On 3/25/20 11:52 AM, Philipp Kunz wrote:
> Hi Naoto,
> 
> See another patch attached with Locale.ROOT for the BreakIterator. I 
> will be glad to hear of any feedback.

I wonder how your change affects the performance, as it will do 
String.getBytes(UTF-8) per each character. I think this can definitely 
be improved by adding some fastpath, e.g., for ASCII. The usage of the 
BreakIterator is fine, though.

> 
> There is another patch [1] around dealing with manifest attributes 
> during application launch. It certainly is related to 6202130 but feels 
> like a distinct set of changes with a slightly different concern. Any 
> opinion as how to proceed with that one?

I am not quite sure which patch you are referring to, but I agree that 
creating an issue would not hurt.

Naoto

> 
> Regards,
> Philipp
> 
> 
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064720.html
> 
> 
> On Mon, 2020-03-23 at 09:05 -0700, naoto.sato at oracle.com wrote:
>> Hi Philipp,
>>
>> Right, Locale.ROOT is more appropriate here by definition, though the
>> implementation is the same.
>>
>> Naoto
>>
>> On 3/21/20 5:19 AM, Philipp Kunz wrote:
>>> Hi Naoto and everyone,
>>>
>>> There are almost as many occurrences of Locale.ROOT as Locale.US which
>>> made me wonder which one is more appropriately locale-independent and
>>> which is probably another topic and not actually relevant here because
>>> BreakIterator.getCharacterInstance is locale-agnostic as far as I can tell.
>>>
>>> See attached patch with another attempt to fix bug 6202130.
>>>
>>> Regards,
>>> Philipp
>>>
>>>
>>> On Tue, 2020-03-10 at 10:45 -0700,
>>> naoto.sato at oracle.com
>>>  <mailto:naoto.sato at oracle.com>
>>>   wrote:
>>>> Hi Philipp,
>>>>
>>>> ..., so using BreakIterator (with
>>>> Locale.US) is more preferred solution to me.
>>>>
>>>> Naoto
>>>