<i18n dev> RFR: 8364365: HKSCS encoder does not properly set the replacement character [v2]

Volkan Yazici vyazici at openjdk.org
Thu Aug 7 15:07:10 UTC 2025


On Wed, 6 Aug 2025 00:25:58 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 139:
>> 
>>> 137:             return coderResult.isUnmappable();
>>> 138:         };
>>> 139:     }
>> 
>> I'd appreciate it if you can double-check these _"Is the given `char[]` unmappable for a particular encoder?"_ test generators.
>
> I might be missing something you're trying to do here,  but any reason why we can't just do
> 
>   return c -> !encoder.canEncode(c[0]);
> 
> as the predicate? I think we are doing 'single char', no surrogates,  here, right?
> 
> or simply go with
> 
>     private static char[] findUnmappable(CharsetEncoder encoder) {
>         for (char c = 0; c <= 0xff; c++) {
>             if (!encoder.canEncode(c))
>                 return new char[]{c};
>         }
>         System.err.println("Could not find an unmappable character!");
>         return null;
>     }

You're right. Simplified as suggested in ba1e5ff4de6.

I wanted to use `{Single,Double}Byte.Encoder` methods deliberately, since those were the ones triggering the failure. Though `CharsetEncoder#canEncode(char)` should do the trick, plus, it is public.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2260610086


More information about the i18n-dev mailing list