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.gibb...@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@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.gibb...@oracle.com>
Sent: Friday, January 18, 2019 4:36 PM
To: Andrew Luo <andrewluotechnolog...@outlook.com>;
code-tools-...@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
