Supporting WSL in shell tests; was Re: [PATCH] Fix for EXE_SUFFIX being set for WSL having no effect

Wed Jan 23 20:29:24 UTC 2019

Thanks, Shura,

While there may be no immediate plans for Oracle to use WSL to build and 
test JDK, there are definitely other folk who are interested in running 
the tests in as easy a way as possible, perhaps in furtherance of their 
own efforts to provide contributions to OpenJDK, and that suggests 
continuing this work at some reasonable level of priority.

And while I too have been trying to include the various component teams 
in the discussions regarding their tests, with my jtreg-hat on, I would 
prefer not to see 6 or more different proposals from the various email 
lists you mention. So I think it is also good to work on a somewhat 
coordinated response to the issues here, so that everything (jtreg and 
component teams' tests) end up on the same page.

My sense is that, from the beginning, the model for shell scripts to 
accommodate platform differences has been to have a case-statement that 
allows different platforms to set variables appropriately. To minimize 
the impact of WSL on tests, I think we should continue that model, which 
comes down to determining the "kind" of the platform, and then executing 
a case-statement with the "kind" as the control variable.

And so, to me, this comes down to "what is the best way to determine the 
"kind" of the platform?"  Up to now, we have used `uname -s` but from 
what I understand, WSL reports "linux" (is that correct?) which means we 
either need a different indicator or we need to refine the analysis.

It's also worth noting that, at least in times past, it has been useful 
to develop and debug these scripts outside of jtreg, which means we must 
not wholly depend on jtreg to set a slew of variables in all cases. 
That's not to say that we might not short-circuit some logic if jtreg 
does set variables.

-- Jon

On 1/23/19 12:09 PM, Alexandre (Shura) Iline wrote:
> Hi,
>
> It is great to have JTReg supporting WSL, of course.
>
> I understand that the plan is to change the tests so they will be both Cygwin- and WSL-compatible. That is important because JDK still needs to support older MS Windows releases.
>
> AFAIK, at least on our end, there are no immediate plans to start using test execution on WSL. I therefore imagine test updates may not be the highest priority.
>
> Regardless, since tests belong to different components of JDK, the discussion of updating tests should happen on appropriate opened aliases, including, but perhaps not limited to,
> core-libs-dev, hotspot-dev, security-dev, client-dev, swing-dev, awt-dev.
>
> I imagine that creating enhancements or tasks for different components in JBS would be a good start also.
>
> Shura
>
>
>
>> On Jan 22, 2019, at 4:16 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> cc: quality-discuss
>> bcc: code-tools-dev
>>
>> This is now turning into a discussion on the way we want to modify tests to accommodate WSL, and so I think we should carry on this discussion on the quality-discuss at openjdk.java.net alias. I want to make sure that we get input from the folk that write, debug and maintain these tests. Once we decide on how we would like to modify the coding patter in tests, then we can determine how best to support that from jtreg.
>>
>> Of particular interest, it would help to know how these tests are used these days. It used to be the case that it was important for these shell tests to be able to run standalone, without the use of jtreg at all. If that is still the case, we cannot overly rely on jtreg to set lots of variables. If we only ever run shell tests from jtreg these days, they we could remove a bunch of boilerplate and have jtreg set more info in env variables. The reality is probably somewhere in between, which is why we need test authors to chime in here.
>>
>> -- Jon
>>
>>
>>
>> On 01/18/2019 07:59 PM, Andrew Luo wrote:
>>> EXE_SUFFIX being .exe guarantees you that it is a Windows JVM under test (WSL currently), but I think EXE_SUFFIX could also be used for Cygwin as well (even though it is not used currently).  Or perhaps another emulation layer, if we add support for yet another one in the future.  But aside from that, I think from the perspective of clarity, it's not obviously (to someone that has no context) that EXE_SUFFIX == .exe => WSL and not Cygwin, because EXE_SUFFIX could be .exe on all Windows platforms.  But if we set WSL_TARGET == windows, it's pretty obvious that that environment variable means WSL.  Of course, the possibility of supporting another emulation layer is purely theoretical at this point, so if you have a strong preference, it doesn't matter that much to me.
>>>
>>> But if I had a choice between the above (EXE_SUFFIX == .exe => WSL_TARGET = windows) and WSL_TARGET == windows => EXE_SUFFIX = .exe, I would prefer the latter, because EXE_SUFFIX doesn't explicitly guarantee you are on WSL.
>>>
>>> Anyways, I want to hear any other thoughts on this...
>>>
>>> Thanks,
>>>
>>> -Andrew
>>>
>>> -----Original Message-----
>>> From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
>>> Sent: Friday, January 18, 2019 4:36 PM
>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; code-tools-dev at openjdk.java.net
>>> Subject: Re: [PATCH] Fix for EXE_SUFFIX being set for WSL having no effect
>>>
>>>
>>>
>>> On 01/18/2019 03:56 PM, Jonathan Gibbons wrote:
>>>> On a (somewhat related note), another thing I noticed is that some
>>>> scripts have logic such as:
>>>>
>>>> OS=`uname -s`;
>>>> # Set classpath separator
>>>> case "$OS" in
>>>>            Windows* | CYGWIN* )
>>>>      SEP=";"
>>>>            ;;
>>>>
>>>>      * )
>>>>      SEP=":"
>>>> esac
>>>>
>>>> However, the classpath separator would depend on the platform of the
>>>> JVM under test (; for a Windows JVM under test, : for a Linux JVM
>>>> under test).  I could copy the above logic to detect the JVM under
>>>> test in the script, but this seems like overkill just to check whether
>>>> your target JVM is Windows or Linux.  So perhaps we could add another
>>>> environment variable, say WSL_TARGET, which would either be set to
>>>> "windows" for a Windows WSL target, or empty for Linux WSL
>>>> target/non-WSL.  That way the above logic could be rewritten:
>>>>
>>>> OS=`uname -s`;
>>>> # Set classpath separator
>>>> case "$OS" in
>>>>            Windows* | CYGWIN* )
>>>>      SEP=";"
>>>>            ;;
>>>>
>>>>      * )
>>>>      if [ "x${WSL_TARGET}" = "xwindows" ]; then
>>>>          SEP=";"
>>>>      else
>>>>          SEP=":"
>>>>      fi
>>>> esac
>>> Just reading this fragment of your message, I think I'm beginning to see what you may be trying to do.  But WSL_TARGET seems like the wrong way to go.  If you need to use WSL_TARGET to fix up the "*" case, that means you executed "case" on the wrong value in the first place.
>>>
>>> How about the following direction:
>>>
>>> OS=`if [ "x${EXE_SUFFIX}" = "x.exe" ]; then echo "Windows_WSL" ; else uname -s; fi`; # Set classpath separator case "$OS" in
>>>       Windows* | CYGWIN* )
>>>             SEP=";"
>>>             ;;
>>>
>>>       * )
>>>       SEP=":"
>>> esac
>>>
>>> or finesse it a bit:
>>>
>>> SYSTEM=`if [ "x${EXE_SUFFIX}" = "x.exe" ]; then echo "WSL" ; else uname -s; fi`; # Set classpath separator case "$SYSTEM" in
>>>       Windows* | CYGWIN* | WSL )
>>>             SEP=";"
>>>             ;;
>>>
>>>       * )
>>>       SEP=":"
>>> esac
>>>
>>> In other words, isn't EXE_SUFFIX already indirectly telling you that its a Windows JVM under test?
>>>
>>> -- Jon