RFR (JAXP) JDK-8167478 javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException: access denied ("java.io.FilePermission" "sko?ice")"

[Frank Yuan]

Alright, thank you! Then I will check it in.

Frank

> -----Original Message-----
> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> Subject: Re: RFR (JAXP) JDK-8167478 javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException:
> access denied ("java.io.FilePermission" "sko?ice")"
> 
> Looks fine. Paths.get is the way to go.
> 
> -Joe
> 
> On 10/14/16, 2:28 AM, Frank Yuan wrote:
> > Hi Joe
> >
> > After some testing, I am sure current Windows platforms support Unicode although the default charset is Windows-1252. So now I check it by
> trying Paths.get method, which was also suggested by Max.
> >
> > Please check the new webrev http://cr.openjdk.java.net/~fyuan/8167478/webrev.01/
> >
> > Thanks
> > Frank
> >
> >> -----Original Message-----
> >> From: Leo Jiang [mailto:li.jiang at oracle.com]
> >> Subject: Re: RFR (JAXP) JDK-8167478 javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException:
> >> access denied ("java.io.FilePermission" "sko?ice")"
> >>
> >> Hi Frank,
> >>
> >> I suggest you to use the following code snippet to make your code more readable.
> >>
> >>           CharsetEncoder charsetEncoder = Charset.defaultCharset().newEncoder();
> >>           boolean b = charsetEncoder.canEncode(path);// alpha
> >>
> >> Any character in Unicode range would be valid as path if current OS charset is UTF-8 (Unicode series encoding). But if
> >> current encoding setting (code page in Windows) is not UTF, e.g. cp936, the string in Java with inside UTF-16
> >> representation  need to be mapped to the local encoding, that might be failed.
> >>
> >> After modification, the test should be passed on UTF-8 encoding, and the encoding which support the character '\u0159'.
> >>
> >> Thanks,
> >> Leo
> >>
> >> On 10/14/2016 06:49 AM, Joe Wang wrote:
> >>> Hi Frank,
> >>>
> >>> Does this work as expected? The method doesn't seem to validate whether a character is legal as a file name. For
> >>> example, on Windows, the original char (e.g. \u0159) used in the test is legal in a file name, but it didn't pass that
> >>> decode/encode test by the Windows' default encoding (Windows-1252). Does that mean this test will no longer run on Windows?
> >>>
> >>> Thanks,
> >>> Joe
> >>>
> >>> On 10/13/16, 2:05 AM, Frank Yuan wrote:
> >>>> Hi all
> >>>>
> >>>>
> >>>>
> >>>> Would you like to review http://cr.openjdk.java.net/~fyuan/8167478/webrev.00/
> >>>> <http://cr.openjdk.java.net/%7Efyuan/8167478/webrev.00/>  ?
> >>>>
> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167478
> >>>>
> >>>>
> >>>>
> >>>> This is a test bug, because Bug6341770.java is invalid when the system environment doesn’t support non-ascii
> >>>> characters, the test will exit immediately in this condition.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>>
> >>>>
> >>>> Frank
> >>>>
> >>>>
> >>>>