From michel.trudeau at oracle.com  Fri Sep 21 21:12:08 2018
From: michel.trudeau at oracle.com (Michel Trudeau)
Date: Fri, 21 Sep 2018 14:12:08 -0700
Subject: [foreign] test_time timezone trouble (TZ)
In-Reply-To: <548afe90ca8727551817bd4a3b215345@xs4all.nl>
References: <548afe90ca8727551817bd4a3b215345@xs4all.nl>
Message-ID: <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com>

[adding jtreg mailing list to seek out answer about jtreg and TZ on Windows]

On Sep 21, 2018, at 12:44 PM, Jorn Vernee <jbvernee at xs4all.nl> wrote:

Hello guys,

I was running into a problem with the test_time test in StdLibTest. The generator for test values was apparently generating invalid values. After fixing that, all the test iterations were failing because the hours were off by one (the output of LocalDateTime.getHours() is being compared to the output of localtime().hour()). Good thing somebody else on the internet seems to have had the same problem [1]. TL;DR when using the MSVC version of localtime, and when running in cygwin, the function tries to interpret the TZ environment variable, but since that has a unix format (courtesy of cygwin), the interpretation fails and defaults to GMT. When TZ is not set, it defaults to the system default timezone, which is also what's being tested against.

I can get the tests to pass by using `unset TZ` in the cygwin terminal before running them, but I'd have to do that every time I reboot it. I was trying to unset TZ automatically by using jtreq `@run shell unsettz.sh` where unsettz.sh is a file containing just the command `unset TZ`. It seems to be running successfully according to the test output:

ACTION: shell -- Passed. Execution successful
REASON: User specified action: run shell unsettz.sh
TIME:   0.126 seconds
messages:
command: shell unsettz.sh
reason: User specified action: run shell unsettz.sh
elapsed time (seconds): 0.126
STDOUT:
STDERR:

But it doesn't seem to affect the tests itself, and they still fail (still off by 1 hour).

I was wondering if there is a way to let jtreg control environment variables? Or maybe you can suggest a different solution?

The jtreg guide [2] mentions that TZ will be propagated from Windows 'if set', but I need it to be not set, or automatically set to the system's default time zone (by default it's blank).

(other than that, tests are looking good: `passed: 24; failed: 4; error: 1`. I just need to fix structs by value, which on Windows cheats and just passes a pointer. 2 failing tests are from jextract missing)

Thanks,
Jorn

[1] : https://stackoverflow.com/q/11655003
[2] : http://openjdk.java.net/jtreg/tag-spec.html


From jonathan.gibbons at oracle.com  Fri Sep 21 21:29:28 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 21 Sep 2018 14:29:28 -0700
Subject: [foreign] test_time timezone trouble (TZ)
In-Reply-To: <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com>
References: <548afe90ca8727551817bd4a3b215345@xs4all.nl>
 <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com>
Message-ID: <5BA562B8.50807@oracle.com>

Jorn,

There is only limited amount of support for setting env variables in 
jtreg tests, because at least in the
early releases of JDK, the use of environment variables was discouraged.

Using `@run shell unsettz.sh` will not have the desired effect because 
it will only affect the shell
that is created to run your shell script, and will not have a persistent 
environment on any other
process.

If you don't mind always setting a command-line option, you might try 
using `-eTZ=` on the jtreg
command-line, which will unset TZ for all tests, although it would be 
more accurate to say that
it will not set it for any tests.

The only way to change the setting of TZ for any specific test will be 
to do one of the
following:

1. Write the test as a shell script that unsets TZ and then runs any 
Java code, using various
     shell environment variables that will be available; these generally 
begin with "TEST".

2. Write the test as a Java program that execs a child process to run 
Java, with the exact set
     of environment variables you want to pass in. There are system 
properties that identify
     the test JDK, test class path and so on; these generally begin with 
"test.".

These days, writing shell tests is generally discouraged, because it is 
notoriously difficult to get it
right on all relevant platforms, and because these days, it is 
reasonably easy to use either
the Java SE Process[Builder] API or test library API to invoke java.

Hope that helps; if you have follow-up questions, please cc: me directly 
or use one of the jtreg-* aliases,
since I am not on the panama-dev list.

-- Jon

On 09/21/2018 02:12 PM, Michel Trudeau wrote:
> [adding jtreg mailing list to seek out answer about jtreg and TZ on Windows]
>
> On Sep 21, 2018, at 12:44 PM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
>
> Hello guys,
>
> I was running into a problem with the test_time test in StdLibTest. The generator for test values was apparently generating invalid values. After fixing that, all the test iterations were failing because the hours were off by one (the output of LocalDateTime.getHours() is being compared to the output of localtime().hour()). Good thing somebody else on the internet seems to have had the same problem [1]. TL;DR when using the MSVC version of localtime, and when running in cygwin, the function tries to interpret the TZ environment variable, but since that has a unix format (courtesy of cygwin), the interpretation fails and defaults to GMT. When TZ is not set, it defaults to the system default timezone, which is also what's being tested against.
>
> I can get the tests to pass by using `unset TZ` in the cygwin terminal before running them, but I'd have to do that every time I reboot it. I was trying to unset TZ automatically by using jtreq `@run shell unsettz.sh` where unsettz.sh is a file containing just the command `unset TZ`. It seems to be running successfully according to the test output:
>
> ACTION: shell -- Passed. Execution successful
> REASON: User specified action: run shell unsettz.sh
> TIME:   0.126 seconds
> messages:
> command: shell unsettz.sh
> reason: User specified action: run shell unsettz.sh
> elapsed time (seconds): 0.126
> STDOUT:
> STDERR:
>
> But it doesn't seem to affect the tests itself, and they still fail (still off by 1 hour).
>
> I was wondering if there is a way to let jtreg control environment variables? Or maybe you can suggest a different solution?
>
> The jtreg guide [2] mentions that TZ will be propagated from Windows 'if set', but I need it to be not set, or automatically set to the system's default time zone (by default it's blank).
>
> (other than that, tests are looking good: `passed: 24; failed: 4; error: 1`. I just need to fix structs by value, which on Windows cheats and just passes a pointer. 2 failing tests are from jextract missing)
>
> Thanks,
> Jorn
>
> [1] : https://stackoverflow.com/q/11655003
> [2] : http://openjdk.java.net/jtreg/tag-spec.html
>


From jbvernee at xs4all.nl  Fri Sep 21 23:18:41 2018
From: jbvernee at xs4all.nl (Jorn Vernee)
Date: Sat, 22 Sep 2018 01:18:41 +0200
Subject: [foreign] test_time timezone trouble (TZ)
In-Reply-To: <5BA562B8.50807@oracle.com>
References: <548afe90ca8727551817bd4a3b215345@xs4all.nl>
 <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com>
 <5BA562B8.50807@oracle.com>
Message-ID: <1bb49bb555e050b6ce75f3b13e99c767@xs4all.nl>

Hey Jon,

Thanks for the suggestions (and thank you Michel for forwarding!).

I will go with option 2 I think. I'm running the tests through `make 
test`, so I'm not sure how I would use the command-line flag, but 
setting a flag all the time is just what I'm trying to avoid any ways :) 
It doesn't look like there is a way to pass jtreg options from the test 
file itself? (maybe something like `@params "-eTZ="`).

The test is calling a C standard library function, so that is to blame 
for the environment variable dependency.

Thanks,
Jorn

Jonathan Gibbons schreef op 2018-09-21 23:29:
> Jorn,
> 
> There is only limited amount of support for setting env variables in
> jtreg tests, because at least in the
> early releases of JDK, the use of environment variables was 
> discouraged.
> 
> Using `@run shell unsettz.sh` will not have the desired effect because
> it will only affect the shell
> that is created to run your shell script, and will not have a
> persistent environment on any other
> process.
> 
> If you don't mind always setting a command-line option, you might try
> using `-eTZ=` on the jtreg
> command-line, which will unset TZ for all tests, although it would be
> more accurate to say that
> it will not set it for any tests.
> 
> The only way to change the setting of TZ for any specific test will be
> to do one of the
> following:
> 
> 1. Write the test as a shell script that unsets TZ and then runs any
> Java code, using various
>     shell environment variables that will be available; these
> generally begin with "TEST".
> 
> 2. Write the test as a Java program that execs a child process to run
> Java, with the exact set
>     of environment variables you want to pass in. There are system
> properties that identify
>     the test JDK, test class path and so on; these generally begin with 
> "test.".
> 
> These days, writing shell tests is generally discouraged, because it
> is notoriously difficult to get it
> right on all relevant platforms, and because these days, it is
> reasonably easy to use either
> the Java SE Process[Builder] API or test library API to invoke java.
> 
> Hope that helps; if you have follow-up questions, please cc: me
> directly or use one of the jtreg-* aliases,
> since I am not on the panama-dev list.
> 
> -- Jon
> 
> On 09/21/2018 02:12 PM, Michel Trudeau wrote:
>> [adding jtreg mailing list to seek out answer about jtreg and TZ on 
>> Windows]
>> 
>> On Sep 21, 2018, at 12:44 PM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
>> 
>> Hello guys,
>> 
>> I was running into a problem with the test_time test in StdLibTest. 
>> The generator for test values was apparently generating invalid 
>> values. After fixing that, all the test iterations were failing 
>> because the hours were off by one (the output of 
>> LocalDateTime.getHours() is being compared to the output of 
>> localtime().hour()). Good thing somebody else on the internet seems to 
>> have had the same problem [1]. TL;DR when using the MSVC version of 
>> localtime, and when running in cygwin, the function tries to interpret 
>> the TZ environment variable, but since that has a unix format 
>> (courtesy of cygwin), the interpretation fails and defaults to GMT. 
>> When TZ is not set, it defaults to the system default timezone, which 
>> is also what's being tested against.
>> 
>> I can get the tests to pass by using `unset TZ` in the cygwin terminal 
>> before running them, but I'd have to do that every time I reboot it. I 
>> was trying to unset TZ automatically by using jtreq `@run shell 
>> unsettz.sh` where unsettz.sh is a file containing just the command 
>> `unset TZ`. It seems to be running successfully according to the test 
>> output:
>> 
>> ACTION: shell -- Passed. Execution successful
>> REASON: User specified action: run shell unsettz.sh
>> TIME:   0.126 seconds
>> messages:
>> command: shell unsettz.sh
>> reason: User specified action: run shell unsettz.sh
>> elapsed time (seconds): 0.126
>> STDOUT:
>> STDERR:
>> 
>> But it doesn't seem to affect the tests itself, and they still fail 
>> (still off by 1 hour).
>> 
>> I was wondering if there is a way to let jtreg control environment 
>> variables? Or maybe you can suggest a different solution?
>> 
>> The jtreg guide [2] mentions that TZ will be propagated from Windows 
>> 'if set', but I need it to be not set, or automatically set to the 
>> system's default time zone (by default it's blank).
>> 
>> (other than that, tests are looking good: `passed: 24; failed: 4; 
>> error: 1`. I just need to fix structs by value, which on Windows 
>> cheats and just passes a pointer. 2 failing tests are from jextract 
>> missing)
>> 
>> Thanks,
>> Jorn
>> 
>> [1] : https://stackoverflow.com/q/11655003
>> [2] : http://openjdk.java.net/jtreg/tag-spec.html
>> 

From jonathan.gibbons at oracle.com  Fri Sep 21 23:30:35 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 21 Sep 2018 16:30:35 -0700
Subject: [foreign] test_time timezone trouble (TZ)
In-Reply-To: <1bb49bb555e050b6ce75f3b13e99c767@xs4all.nl>
References: <548afe90ca8727551817bd4a3b215345@xs4all.nl>
 <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com> <5BA562B8.50807@oracle.com>
 <1bb49bb555e050b6ce75f3b13e99c767@xs4all.nl>
Message-ID: <5BA57F1B.5060602@oracle.com>

Jorn,

Yes, short term, I would recommend option 2 as the way to go. There 
should be examples to copy, and if you want to get cute and avoid 
another source file, your test could have a main program that checks if 
TZ is set, and if so, it re-execs itself without TZ.

Long term, I think the right way to handle this would be either as an 
option or an argument on the "@run main" and "@run shell" action tags.

Neither are great, syntax-wise, but either would be good enough for your 
specific case:

For example,

main[/fail][/manual][/othervm][/policy=<file>][/secure=<class>] 
[/timeout=<seconds>][/e:NAME=VALUE]* <vm-opt>* <class> <arg>*

main[/fail][/manual][/othervm][/policy=<file>][/secure=<class>] 
[/timeout=<seconds>] [NAME=VALUE]* <vm-opt>* <class> <arg>*

I'll file an RFE for jtreg.

-- Jon

On 09/21/2018 04:18 PM, Jorn Vernee wrote:
> Hey Jon,
>
> Thanks for the suggestions (and thank you Michel for forwarding!).
>
> I will go with option 2 I think. I'm running the tests through `make 
> test`, so I'm not sure how I would use the command-line flag, but 
> setting a flag all the time is just what I'm trying to avoid any ways 
> :) It doesn't look like there is a way to pass jtreg options from the 
> test file itself? (maybe something like `@params "-eTZ="`).
>
> The test is calling a C standard library function, so that is to blame 
> for the environment variable dependency.
>
> Thanks,
> Jorn
>
> Jonathan Gibbons schreef op 2018-09-21 23:29:
>> Jorn,
>>
>> There is only limited amount of support for setting env variables in
>> jtreg tests, because at least in the
>> early releases of JDK, the use of environment variables was discouraged.
>>
>> Using `@run shell unsettz.sh` will not have the desired effect because
>> it will only affect the shell
>> that is created to run your shell script, and will not have a
>> persistent environment on any other
>> process.
>>
>> If you don't mind always setting a command-line option, you might try
>> using `-eTZ=` on the jtreg
>> command-line, which will unset TZ for all tests, although it would be
>> more accurate to say that
>> it will not set it for any tests.
>>
>> The only way to change the setting of TZ for any specific test will be
>> to do one of the
>> following:
>>
>> 1. Write the test as a shell script that unsets TZ and then runs any
>> Java code, using various
>>     shell environment variables that will be available; these
>> generally begin with "TEST".
>>
>> 2. Write the test as a Java program that execs a child process to run
>> Java, with the exact set
>>     of environment variables you want to pass in. There are system
>> properties that identify
>>     the test JDK, test class path and so on; these generally begin 
>> with "test.".
>>
>> These days, writing shell tests is generally discouraged, because it
>> is notoriously difficult to get it
>> right on all relevant platforms, and because these days, it is
>> reasonably easy to use either
>> the Java SE Process[Builder] API or test library API to invoke java.
>>
>> Hope that helps; if you have follow-up questions, please cc: me
>> directly or use one of the jtreg-* aliases,
>> since I am not on the panama-dev list.
>>
>> -- Jon
>>
>> On 09/21/2018 02:12 PM, Michel Trudeau wrote:
>>> [adding jtreg mailing list to seek out answer about jtreg and TZ on 
>>> Windows]
>>>
>>> On Sep 21, 2018, at 12:44 PM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
>>>
>>> Hello guys,
>>>
>>> I was running into a problem with the test_time test in StdLibTest. 
>>> The generator for test values was apparently generating invalid 
>>> values. After fixing that, all the test iterations were failing 
>>> because the hours were off by one (the output of 
>>> LocalDateTime.getHours() is being compared to the output of 
>>> localtime().hour()). Good thing somebody else on the internet seems 
>>> to have had the same problem [1]. TL;DR when using the MSVC version 
>>> of localtime, and when running in cygwin, the function tries to 
>>> interpret the TZ environment variable, but since that has a unix 
>>> format (courtesy of cygwin), the interpretation fails and defaults 
>>> to GMT. When TZ is not set, it defaults to the system default 
>>> timezone, which is also what's being tested against.
>>>
>>> I can get the tests to pass by using `unset TZ` in the cygwin 
>>> terminal before running them, but I'd have to do that every time I 
>>> reboot it. I was trying to unset TZ automatically by using jtreq 
>>> `@run shell unsettz.sh` where unsettz.sh is a file containing just 
>>> the command `unset TZ`. It seems to be running successfully 
>>> according to the test output:
>>>
>>> ACTION: shell -- Passed. Execution successful
>>> REASON: User specified action: run shell unsettz.sh
>>> TIME:   0.126 seconds
>>> messages:
>>> command: shell unsettz.sh
>>> reason: User specified action: run shell unsettz.sh
>>> elapsed time (seconds): 0.126
>>> STDOUT:
>>> STDERR:
>>>
>>> But it doesn't seem to affect the tests itself, and they still fail 
>>> (still off by 1 hour).
>>>
>>> I was wondering if there is a way to let jtreg control environment 
>>> variables? Or maybe you can suggest a different solution?
>>>
>>> The jtreg guide [2] mentions that TZ will be propagated from Windows 
>>> 'if set', but I need it to be not set, or automatically set to the 
>>> system's default time zone (by default it's blank).
>>>
>>> (other than that, tests are looking good: `passed: 24; failed: 4; 
>>> error: 1`. I just need to fix structs by value, which on Windows 
>>> cheats and just passes a pointer. 2 failing tests are from jextract 
>>> missing)
>>>
>>> Thanks,
>>> Jorn
>>>
>>> [1] : https://stackoverflow.com/q/11655003
>>> [2] : http://openjdk.java.net/jtreg/tag-spec.html
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20180921/536d1af4/attachment-0001.html>

From jbvernee at xs4all.nl  Sat Sep 22 00:03:17 2018
From: jbvernee at xs4all.nl (Jorn Vernee)
Date: Sat, 22 Sep 2018 02:03:17 +0200
Subject: [foreign] test_time timezone trouble (TZ)
In-Reply-To: <5BA57F1B.5060602@oracle.com>
References: <548afe90ca8727551817bd4a3b215345@xs4all.nl>
 <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com>
 <5BA562B8.50807@oracle.com> <1bb49bb555e050b6ce75f3b13e99c767@xs4all.nl>
 <5BA57F1B.5060602@oracle.com>
Message-ID: <4f1c91598879b9236d46650c74ff366b@xs4all.nl>

Hey Jon,

One of the other panama guys suggested to just drop the localtime() test 
and call gmtime() instead, which does not have the environment variable 
dependency. We currently have the luxury to do that, but the future 
might be different, so thanks for the RFE.

FWIW the file in question [1] is using the '@run testng' action tag, so 
the option would need to be added there as well I guess.

Jorn

[1] : 
http://hg.openjdk.java.net/panama/dev/file/01ecea66dd99/test/jdk/java/foreign/StdLibTest.java

Jonathan Gibbons schreef op 2018-09-22 01:30:
> Jorn,
> 
> Yes, short term, I would recommend option 2 as the way to go. There
> should be examples to copy, and if you want to get cute and avoid
> another source file, your test could have a main program that checks
> if TZ is set, and if so, it re-execs itself without TZ.
> 
> Long term, I think the right way to handle this would be either as an
> option or an argument on the "@run main" and "@run shell" action tags.
> 
> Neither are great, syntax-wise, but either would be good enough for
> your specific case:
> 
> For example,
> 
> main[/fail][/manual][/othervm][/policy=<file>][/secure=<class>]
> [/timeout=<seconds>][/e:NAME=VALUE]* <vm-opt>* <class> <arg>*
> 
> main[/fail][/manual][/othervm][/policy=<file>][/secure=<class>]
> [/timeout=<seconds>] [NAME=VALUE]* <vm-opt>* <class> <arg>*
> 
> I'll file an RFE for jtreg.
> 
> -- Jon
> 
> On 09/21/2018 04:18 PM, Jorn Vernee wrote:
> 
>> Hey Jon,
>> 
>> Thanks for the suggestions (and thank you Michel for forwarding!).
>> 
>> I will go with option 2 I think. I'm running the tests through `make
>> test`, so I'm not sure how I would use the command-line flag, but
>> setting a flag all the time is just what I'm trying to avoid any
>> ways :) It doesn't look like there is a way to pass jtreg options
>> from the test file itself? (maybe something like `@params "-eTZ="`).
>> 
>> 
>> The test is calling a C standard library function, so that is to
>> blame for the environment variable dependency.
>> 
>> Thanks,
>> Jorn
>> 
>> Jonathan Gibbons schreef op 2018-09-21 23:29:
>> Jorn,
>> 
>> There is only limited amount of support for setting env variables in
>> 
>> jtreg tests, because at least in the
>> early releases of JDK, the use of environment variables was
>> discouraged.
>> 
>> Using `@run shell unsettz.sh` will not have the desired effect
>> because
>> it will only affect the shell
>> that is created to run your shell script, and will not have a
>> persistent environment on any other
>> process.
>> 
>> If you don't mind always setting a command-line option, you might
>> try
>> using `-eTZ=` on the jtreg
>> command-line, which will unset TZ for all tests, although it would
>> be
>> more accurate to say that
>> it will not set it for any tests.
>> 
>> The only way to change the setting of TZ for any specific test will
>> be
>> to do one of the
>> following:
>> 
>> 1. Write the test as a shell script that unsets TZ and then runs any
>> 
>> Java code, using various
>> shell environment variables that will be available; these
>> generally begin with "TEST".
>> 
>> 2. Write the test as a Java program that execs a child process to
>> run
>> Java, with the exact set
>> of environment variables you want to pass in. There are system
>> properties that identify
>> the test JDK, test class path and so on; these generally begin
>> with "test.".
>> 
>> These days, writing shell tests is generally discouraged, because it
>> 
>> is notoriously difficult to get it
>> right on all relevant platforms, and because these days, it is
>> reasonably easy to use either
>> the Java SE Process[Builder] API or test library API to invoke java.
>> 
>> 
>> Hope that helps; if you have follow-up questions, please cc: me
>> directly or use one of the jtreg-* aliases,
>> since I am not on the panama-dev list.
>> 
>> -- Jon
>> 
>> On 09/21/2018 02:12 PM, Michel Trudeau wrote:
>> [adding jtreg mailing list to seek out answer about jtreg and TZ on
>> Windows]
>> 
>> On Sep 21, 2018, at 12:44 PM, Jorn Vernee <jbvernee at xs4all.nl>
>> wrote:
>> 
>> Hello guys,
>> 
>> I was running into a problem with the test_time test in StdLibTest.
>> The generator for test values was apparently generating invalid
>> values. After fixing that, all the test iterations were failing
>> because the hours were off by one (the output of
>> LocalDateTime.getHours() is being compared to the output of
>> localtime().hour()). Good thing somebody else on the internet seems
>> to have had the same problem [1]. TL;DR when using the MSVC version
>> of localtime, and when running in cygwin, the function tries to
>> interpret the TZ environment variable, but since that has a unix
>> format (courtesy of cygwin), the interpretation fails and defaults
>> to GMT. When TZ is not set, it defaults to the system default
>> timezone, which is also what's being tested against.
>> 
>> I can get the tests to pass by using `unset TZ` in the cygwin
>> terminal before running them, but I'd have to do that every time I
>> reboot it. I was trying to unset TZ automatically by using jtreq
>> `@run shell unsettz.sh` where unsettz.sh is a file containing just
>> the command `unset TZ`. It seems to be running successfully
>> according to the test output:
>> 
>> ACTION: shell -- Passed. Execution successful
>> REASON: User specified action: run shell unsettz.sh
>> TIME:   0.126 seconds
>> messages:
>> command: shell unsettz.sh
>> reason: User specified action: run shell unsettz.sh
>> elapsed time (seconds): 0.126
>> STDOUT:
>> STDERR:
>> 
>> But it doesn't seem to affect the tests itself, and they still fail
>> (still off by 1 hour).
>> 
>> I was wondering if there is a way to let jtreg control environment
>> variables? Or maybe you can suggest a different solution?
>> 
>> The jtreg guide [2] mentions that TZ will be propagated from Windows
>> 'if set', but I need it to be not set, or automatically set to the
>> system's default time zone (by default it's blank).
>> 
>> (other than that, tests are looking good: `passed: 24; failed: 4;
>> error: 1`. I just need to fix structs by value, which on Windows
>> cheats and just passes a pointer. 2 failing tests are from jextract
>> missing)
>> 
>> Thanks,
>> Jorn
>> 
>> [1] : https://stackoverflow.com/q/11655003
>> [2] : http://openjdk.java.net/jtreg/tag-spec.html

From jonathan.gibbons at oracle.com  Sat Sep 22 00:05:32 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 21 Sep 2018 17:05:32 -0700
Subject: [foreign] test_time timezone trouble (TZ)
In-Reply-To: <4f1c91598879b9236d46650c74ff366b@xs4all.nl>
References: <548afe90ca8727551817bd4a3b215345@xs4all.nl>
 <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com> <5BA562B8.50807@oracle.com>
 <1bb49bb555e050b6ce75f3b13e99c767@xs4all.nl> <5BA57F1B.5060602@oracle.com>
 <4f1c91598879b9236d46650c74ff366b@xs4all.nl>
Message-ID: <5BA5874C.80309@oracle.com>

I'm pleased that you found an even simpler solution to your problem.

Thanks for the note about TestNG.

-- Jon

On 09/21/2018 05:03 PM, Jorn Vernee wrote:
> Hey Jon,
>
> One of the other panama guys suggested to just drop the localtime() 
> test and call gmtime() instead, which does not have the environment 
> variable dependency. We currently have the luxury to do that, but the 
> future might be different, so thanks for the RFE.
>
> FWIW the file in question [1] is using the '@run testng' action tag, 
> so the option would need to be added there as well I guess.
>
> Jorn
>
> [1] : 
> http://hg.openjdk.java.net/panama/dev/file/01ecea66dd99/test/jdk/java/foreign/StdLibTest.java
>
> Jonathan Gibbons schreef op 2018-09-22 01:30:
>> Jorn,
>>
>> Yes, short term, I would recommend option 2 as the way to go. There
>> should be examples to copy, and if you want to get cute and avoid
>> another source file, your test could have a main program that checks
>> if TZ is set, and if so, it re-execs itself without TZ.
>>
>> Long term, I think the right way to handle this would be either as an
>> option or an argument on the "@run main" and "@run shell" action tags.
>>
>> Neither are great, syntax-wise, but either would be good enough for
>> your specific case:
>>
>> For example,
>>
>> main[/fail][/manual][/othervm][/policy=<file>][/secure=<class>]
>> [/timeout=<seconds>][/e:NAME=VALUE]* <vm-opt>* <class> <arg>*
>>
>> main[/fail][/manual][/othervm][/policy=<file>][/secure=<class>]
>> [/timeout=<seconds>] [NAME=VALUE]* <vm-opt>* <class> <arg>*
>>
>> I'll file an RFE for jtreg.
>>
>> -- Jon
>>
>> On 09/21/2018 04:18 PM, Jorn Vernee wrote:
>>
>>> Hey Jon,
>>>
>>> Thanks for the suggestions (and thank you Michel for forwarding!).
>>>
>>> I will go with option 2 I think. I'm running the tests through `make
>>> test`, so I'm not sure how I would use the command-line flag, but
>>> setting a flag all the time is just what I'm trying to avoid any
>>> ways :) It doesn't look like there is a way to pass jtreg options
>>> from the test file itself? (maybe something like `@params "-eTZ="`).
>>>
>>>
>>> The test is calling a C standard library function, so that is to
>>> blame for the environment variable dependency.
>>>
>>> Thanks,
>>> Jorn
>>>
>>> Jonathan Gibbons schreef op 2018-09-21 23:29:
>>> Jorn,
>>>
>>> There is only limited amount of support for setting env variables in
>>>
>>> jtreg tests, because at least in the
>>> early releases of JDK, the use of environment variables was
>>> discouraged.
>>>
>>> Using `@run shell unsettz.sh` will not have the desired effect
>>> because
>>> it will only affect the shell
>>> that is created to run your shell script, and will not have a
>>> persistent environment on any other
>>> process.
>>>
>>> If you don't mind always setting a command-line option, you might
>>> try
>>> using `-eTZ=` on the jtreg
>>> command-line, which will unset TZ for all tests, although it would
>>> be
>>> more accurate to say that
>>> it will not set it for any tests.
>>>
>>> The only way to change the setting of TZ for any specific test will
>>> be
>>> to do one of the
>>> following:
>>>
>>> 1. Write the test as a shell script that unsets TZ and then runs any
>>>
>>> Java code, using various
>>> shell environment variables that will be available; these
>>> generally begin with "TEST".
>>>
>>> 2. Write the test as a Java program that execs a child process to
>>> run
>>> Java, with the exact set
>>> of environment variables you want to pass in. There are system
>>> properties that identify
>>> the test JDK, test class path and so on; these generally begin
>>> with "test.".
>>>
>>> These days, writing shell tests is generally discouraged, because it
>>>
>>> is notoriously difficult to get it
>>> right on all relevant platforms, and because these days, it is
>>> reasonably easy to use either
>>> the Java SE Process[Builder] API or test library API to invoke java.
>>>
>>>
>>> Hope that helps; if you have follow-up questions, please cc: me
>>> directly or use one of the jtreg-* aliases,
>>> since I am not on the panama-dev list.
>>>
>>> -- Jon
>>>
>>> On 09/21/2018 02:12 PM, Michel Trudeau wrote:
>>> [adding jtreg mailing list to seek out answer about jtreg and TZ on
>>> Windows]
>>>
>>> On Sep 21, 2018, at 12:44 PM, Jorn Vernee <jbvernee at xs4all.nl>
>>> wrote:
>>>
>>> Hello guys,
>>>
>>> I was running into a problem with the test_time test in StdLibTest.
>>> The generator for test values was apparently generating invalid
>>> values. After fixing that, all the test iterations were failing
>>> because the hours were off by one (the output of
>>> LocalDateTime.getHours() is being compared to the output of
>>> localtime().hour()). Good thing somebody else on the internet seems
>>> to have had the same problem [1]. TL;DR when using the MSVC version
>>> of localtime, and when running in cygwin, the function tries to
>>> interpret the TZ environment variable, but since that has a unix
>>> format (courtesy of cygwin), the interpretation fails and defaults
>>> to GMT. When TZ is not set, it defaults to the system default
>>> timezone, which is also what's being tested against.
>>>
>>> I can get the tests to pass by using `unset TZ` in the cygwin
>>> terminal before running them, but I'd have to do that every time I
>>> reboot it. I was trying to unset TZ automatically by using jtreq
>>> `@run shell unsettz.sh` where unsettz.sh is a file containing just
>>> the command `unset TZ`. It seems to be running successfully
>>> according to the test output:
>>>
>>> ACTION: shell -- Passed. Execution successful
>>> REASON: User specified action: run shell unsettz.sh
>>> TIME:   0.126 seconds
>>> messages:
>>> command: shell unsettz.sh
>>> reason: User specified action: run shell unsettz.sh
>>> elapsed time (seconds): 0.126
>>> STDOUT:
>>> STDERR:
>>>
>>> But it doesn't seem to affect the tests itself, and they still fail
>>> (still off by 1 hour).
>>>
>>> I was wondering if there is a way to let jtreg control environment
>>> variables? Or maybe you can suggest a different solution?
>>>
>>> The jtreg guide [2] mentions that TZ will be propagated from Windows
>>> 'if set', but I need it to be not set, or automatically set to the
>>> system's default time zone (by default it's blank).
>>>
>>> (other than that, tests are looking good: `passed: 24; failed: 4;
>>> error: 1`. I just need to fix structs by value, which on Windows
>>> cheats and just passes a pointer. 2 failing tests are from jextract
>>> missing)
>>>
>>> Thanks,
>>> Jorn
>>>
>>> [1] : https://stackoverflow.com/q/11655003
>>> [2] : http://openjdk.java.net/jtreg/tag-spec.html


From lin.zang.z at gmail.com  Sun Sep 30 06:04:28 2018
From: lin.zang.z at gmail.com (Lin Zang)
Date: Sat, 29 Sep 2018 23:04:28 -0700 (MST)
Subject: fail when "make run-test-tier1" and "make all"
Message-ID: <1538287468411-0.post@n7.nabble.com>

Hi, 
    I recently tried to runt make run-test-tier1 or make all on jdk10u and
jdk11 with latest jtreg. all fail with following error:

ERROR: Build failed for target 'run-test-tier1' in configuration
'linux-x86_64-normal-server-release' (exit code 2) 
Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target
support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:
/media/Source/jdk11/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:123:
error: no suitable method found for save(Map<CAP#1,CAP#2>)
        rp.save(map);
          ^
    method InterviewParameters.save(File) is not applicable
      (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to File)
    method InterviewParameters.save(Map<String,String>) is not applicable
      (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
Map<String,String>)
  where CAP#1,CAP#2 are fresh type-variables:
    CAP#1 extends Object from capture of ?
    CAP#2 extends Object from capture of ?
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
   ... (rest of output omitted)

* All command lines available in
/media/Source/jdk11/build/linux-x86_64-normal-server-release/make-support/failure-logs.
=== End of repeated output ===

=== Make failed targets repeated here ===
BuildFailureHandler.gmk:51: recipe for target
'/media/Source/jdk11/build/linux-x86_64-normal-server-release/support/test/failure_handler/classes/_the.BUILD_FAILURE_HANDLER_batch'
failed
make/Main.gmk:516: recipe for target 'build-test-failure-handler' failed
=== End of repeated output ===

Hint: Try searching the build log for the name of the first failed target.
Hint: See doc/building.html#troubleshooting for assistance.

/media/Source/jdk11/make/Init.gmk:300: recipe for target 'main' failed
make[1]: *** [main] Error 2
/media/Source/jdk11/make/Init.gmk:186: recipe for target 'run-test-tier1'
failed
make: *** [run-test-tier1] Error 2

Can anyone help to take a look at this issue? Thanks

BRs,
Lin



--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-jtreg-Test-Harness-f101415.html

From lin.zang.z at gmail.com  Sun Sep 30 06:07:02 2018
From: lin.zang.z at gmail.com (Lin Zang)
Date: Sat, 29 Sep 2018 23:07:02 -0700 (MST)
Subject: fail when "make run-test-tier1" and "make all"
In-Reply-To: <1538287468411-0.post@n7.nabble.com>
References: <1538287468411-0.post@n7.nabble.com>
Message-ID: <1538287622403-0.post@n7.nabble.com>

Moreover it seems the following change can help fix the issue: 


---
a/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java
+++
b/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java
@@ -119,7 +119,7 @@ public class GatherDiagnosticInfoObserver implements
Harness.Observer {
     public void startingTestRun(Parameters params) {
         // TODO find a better way to get JDKs
         InterviewParameters rp = (InterviewParameters) params;
-        Map<?,?> map = new HashMap<>();
+        Map<String, String> map = new HashMap<>();
         rp.save(map);
         compileJdk = (String) map.get("regtest.compilejdk");
         testJdk = (String) map.get("regtest.testjdk");

======================================
so is this patch a suitable fix of the issue? 



--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-jtreg-Test-Harness-f101415.html