(10) RFR of JDK-8181912,Refactor locale related shell test test/java/io/File/MacPathTest.sh to java test

[Hamlin Li]

On 2017/6/16 17:14, Felix Yang wrote:
>
> Hamlin,
>
>     this may be not a blocker. if you prefer 'pure' java, it can be 
> achieved by adjusting environment for ProcessBuilder.
>
> see Amy's patch: 
> http://cr.openjdk.java.net/~amlu/8181395/webrev.00/test/java/nio/charset/Charset/DefaultCharsetTest.java.html
>
> In further, you may extend and wrap such usage in ProcessTools, 
> because this looks to be a common usage, at least in encoding use cases.
Good point. Thank you Felix, I will do it.

Thank you
-Hamlin
>
> -Felix
> On 2017/6/16 11:40, Hamlin Li wrote:
>>
>> Hi Felix,
>>
>> Thank you for your suggestions.
>>
>> But I think it's just a java wrapper around a shell, not a real java.
>>
>> Thank you
>>
>> -Hamlin
>>
>>
>> On 2017/6/16 9:41, Felix Yang wrote:
>>>
>>> Hi Hamlin,
>>>
>>>      I think you need something like:
>>>
>>> /ProcessTools.executeCommand("sh", "-c", yourTestCmd).../
>>>
>>> yourTestCmd is like the original cmd in shell "
>>> export LC_ALL=en_US.UTF-8 ;${TESTJAVA}/bin/java ${TESTVMOPTS} -cp ${TESTCLASSES} MacPathTest"
>>> -Felix
>>> On 2017/6/16 9:32, Naoto Sato wrote:
>>>> 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
>>>>>>>
>>>>>
>>>
>>
>