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

[Felix Yang]

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.

-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
>>>>>>
>>>>
>>
>