Hi Hamlin,
What I meant was that setting the java locale either through
Locale.setDefault() or user.language/user.country properties won't
affect the default encoding determination. Other properties
(file.encoding/sun.jnu.encoding) would set the default, but I am not
sure how they are supposed to be used in regression tests.
Naoto
On 6/15/17 4:59 PM, Hamlin Li wrote:
Hi Naoto,
Thank you for comments.
Do you mean there is no way to set encoding through system property or
java API? And can I understand it as it's better to keep the shell test
rather than convert it to java test.
Thank you
-Hamlin
On 2017/6/16 0:45, Naoto Sato wrote:
Hi,
Setting the default Java Locale and/or user.* properties has nothing
to do with the default encoding. The default encoding on mac/unix
environments is determined from the environment variable LC_CTYPE.
Naoto
On 6/14/17 8:35 PM, Hamlin Li wrote:
On 2017/6/15 1:22, Alan Bateman wrote:
On 12/06/2017 09:00, Hamlin Li wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8181912
webrev: http://cr.openjdk.java.net/~mli/8181912/webrev.00/
Are you sure that setting the user.* properties on the command
actually works? I assume we'll have to change this back at some
point to launch the test with LC_ALL set to UTF-8.
Hi Alan,
Besides of setting user.language and user.country, the patch also
sets file.encoding, and sun.jnu.encoding as UTF-8.
I understand your concern: we're not sure if setting -Dxxx properties
will have totally same functionality as setting env variable LC_ALL.
I have no answer for this question.
What tests have been done:
1. set user.* properties will affect what Locale.getDefault() gets,
set file.encoding will affect what
java.nio.charset.Charset.defaultCharset() gets.
2. jprt passed.
3. test on some other mac machine in SQE pool.
Do you suggest we should keep this test as shell?
Thank you
-Hamlin
-Alan
