Looks fine. Paths.get is the way to go.
On 10/14/16, 2:28 AM, Frank Yuan wrote:
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/
From: Leo Jiang [mailto:li.ji...@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")"
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'.
On 10/14/2016 06:49 AM, Joe Wang wrote:
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?
On 10/13/16, 2:05 AM, Frank Yuan wrote:
Would you like to review http://cr.openjdk.java.net/~fyuan/8167478/webrev.00/
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.