
<html><body><p><font size="2">Hi Jon,</font><br><br><font size="2">Could you look at this fix, if possible?</font><br><font size="2">Any comments or suggestions are welcome.</font><br><br><font size="2">Webrev.02: <a href="http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/">http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/</a></font><br><font size="2">Issue: <a href="https://bugs.openjdk.java.net/browse/JDK-8233829">https://bugs.openjdk.java.net/browse/JDK-8233829</a></font><br><font size="2"><br>Best regards,<br><br>Toshio Nakamura<br></font><br><tt><font size="2">> From: "Toshio 5 Nakamura" <TOSHIONA@jp.ibm.com></font></tt><br><tt><font size="2">> To: Jonathan Gibbons <jonathan.gibbons@oracle.com></font></tt><br><tt><font size="2">> Cc: compiler-dev@openjdk.java.net</font></tt><br><tt><font size="2">> Date: 2020/05/15 00:23</font></tt><br><tt><font size="2">> Subject: [EXTERNAL] Re: RFR: JDK-8233829: javac cannot find non-<br>> ASCII module name under non-UTF8 environment</font></tt><br><tt><font size="2">> Sent by: "compiler-dev" <compiler-dev-bounces@openjdk.java.net></font></tt><br><tt><font size="2">> <br>> Hi Jon,<br>> <br>> Thank you for comments.<br>> <br>> Could you check webrev.02 which contains a testcase?<br>> Actually, this is not a direct test of the original problem since <br>> non-English Windows is required.<br>> But, I realized the patch fixed Unicode Surrogate Pair case, as well.<br>> It's caused by difference between Standard UTF-8 and Modified UTF-8,<br>> and it can be checked on English environment.<br>> <br>> I confirmed the test failed without the patch and passed with the patch.<br>> Tier1 tests also pass on Linux and Windows.<br>> <br>> Webrev.02: <a href="http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/">http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/</a><br>> <br>> Best regards,<br>> <br>> Toshio Nakamura<br>> <br>> Jonathan Gibbons <jonathan.gibbons@oracle.com> wrote on 2020/05/14 11:50:03:<br>> <br>> > From: Jonathan Gibbons <jonathan.gibbons@oracle.com><br>> > To: Toshio 5 Nakamura <TOSHIONA@jp.ibm.com>, compiler-dev@openjdk.java.net<br>> > Date: 2020/05/14 11:50<br>> > Subject: [EXTERNAL] Re: RFR: JDK-8233829: javac cannot find non-<br>> > ASCII module name under non-UTF8 environment<br>> > <br>> > Hi,<br>> > Normally, bug fixes like this this should be accompanied by a <br>> > corresponding regression test. While it may be a bit tricky to write<br>> > a test for this situation, it seems like it would be worth having <br>> > the test if possible.<br>> > -- Jon<br>> > On 5/13/20 7:11 PM, Toshio 5 Nakamura wrote:<br>> > Hi,<br>> > <br>> > Can anyone please review this fix?<br>> > Revised the patch simpler. In my understanding, the encoding is <br>> > modified UTF-8 instead of standard UTF-8 in this case. So, the fix <br>> > uses Convert utility class.<br>> > <br>> > Webrev.01: <a href="http://cr.openjdk.java.net/~tnakamura/8233829/webrev.01/">http://cr.openjdk.java.net/~tnakamura/8233829/webrev.01/</a><br>> > <br>> > Best regards,<br>> > Toshio Nakamura<br>> > <br>> > > From: Toshio 5 Nakamura/Japan/IBM<br>> > > To: compiler-dev@openjdk.java.net<br>> > > Date: 2020/04/16 21:39<br>> > > Subject: RFR: JDK-8233829: Non-ASCII module name cannot be handled <br>> > > under non-UTF8 environment<br>> > > <br>> > > Hi all,<br>> > > <br>> > > Could you review this fix? Also, I'd like to ask a sponsor of the fix, since<br>> > > I'm not a committer.<br>> > > <br>> > > Issue: <a href="https://bugs.openjdk.java.net/browse/JDK-8233829">https://bugs.openjdk.java.net/browse/JDK-8233829</a><br>> > > Webrev: <a href="http://cr.openjdk.java.net/~tnakamura/8233829/webrev.00/">http://cr.openjdk.java.net/~tnakamura/8233829/webrev.00/</a><br>> > > <br>> > > If module name is in non-ASCII and environment is in non-UTF8,<br>> > > javac's "--add-modules" option cannot find the module.<br>> > > <br>> > > com.sun.tools.javac.jvm.ModuleNameReader.utf8Mapper uses <br>> > > String(byte[], int, int).<br>> > > In problematic case, the String was generated by default encoding <br>> > > which wasn't UTF8.<br>> > > For example, Japanese Windows uses MS932 (Shift_JIS) encoding.<br>> > > The byte[] in utf8Mapper method is always decoded by UTF-8.<br>> > > <br>> > > Tier1 tests on Linux and Windows passed.<br>> > > <br>> > > Best Regards,<br>> > > Toshio Nakamura</font></tt><BR>

</body></html>