Modified as per Stuart's suggestion.
> On Sep 20, 2018, at 7:45 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>
>
>> On 19 Sep 2018, at 23:21, Stuart Marks <stuart.ma...@oracle.com> wrote:
>>
>> ...
>>
>> 2979 * Each unicode escape in the form \unnnn is translated to the
>> 2980 * unicode character whose code point is {@code 0xnnnn}. Care
>> should be
>> 2981 * taken when using UTF-16 surrogate pairs to ensure that the high
>> 2982 * surrogate (U+D800..U+DBFF) is immediately followed by a low
>> surrogate
>> 2983 * (U+DC00..U+DFFF) otherwise a
>> 2984 * {@link java.nio.charset.CharacterCodingException} may occur
>> during UTF-8
>> 2985 * decoding.
>>
>>
>> I know you're going to update this based on Naoto's comments, but I'd
>> suggest rethinking this section. The \unnnn construct is called a "Unicode
>> escape" per JLS 3.3, but how it's handled has little to do with Unicode. The
>> nnnn digits are simply translated into a 16-bit 'char' value. Any such value
>> will work, even if it's an invalid UTF-16 code unit (such as 0xFFF0) or an
>> unpaired surrogate.
>
> I had a similar comment/question. CCE is a checked exception, and
> since the method does not declare that it throws CCE, I took a look
> at the implementation and came to the same conclusion as Stuart.
>
> Additionally, why should non-character code points, like \uFFFE, be
> translated? If it’s a non-character code point or a malformed surrogate
> pair, would it not be better to just leave it as-is?
>
> -Chris.
