From jonathan.gibbons at oracle.com Thu Mar 12 03:06:52 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 12 Mar 2015 03:06:52 +0000 Subject: hg: code-tools/jtreg: 2 new changesets Message-ID: <201503120306.t2C36qJl020867@aojmv0008> Changeset: 353dd691b9cc Author: jjg Date: 2015-03-11 18:56 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/353dd691b9cc 7901336: Use Process.destroyForcibly() when available Contributed-by: staffan.larsen at oracle.com ! src/share/classes/com/sun/javatest/regtest/Agent.java ! src/share/classes/com/sun/javatest/regtest/Main.java ! src/share/classes/com/sun/javatest/regtest/ProcessCommand.java Changeset: f14a8ea2e528 Author: jjg Date: 2015-03-11 20:06 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/f14a8ea2e528 7901337: Clarifying which mode is the default ! src/share/classes/com/sun/javatest/regtest/i18n.properties From jonathan.gibbons at oracle.com Thu Mar 12 19:56:13 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 12 Mar 2015 19:56:13 +0000 Subject: hg: code-tools/jtreg: 2 new changesets Message-ID: <201503121956.t2CJuDbD017444@aojmv0008> Changeset: 6e691d259587 Author: jjg Date: 2015-03-12 12:00 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/6e691d259587 Add missing file + src/share/classes/com/sun/javatest/regtest/ProcessUtils.java Changeset: 04f40c388713 Author: jjg Date: 2015-03-12 12:55 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/04f40c388713 include resource file in image Contributed-by: staffan.larsen at oracle.com ! make/jtreg.gmk From jonathan.gibbons at oracle.com Tue Mar 17 22:18:24 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 17 Mar 2015 22:18:24 +0000 Subject: hg: code-tools/jtreg: Added tag jtreg4.1-b11 for changeset 04f40c388713 Message-ID: <201503172218.t2HMIPEq014908@aojmv0008> Changeset: 5cb7831aea2e Author: jjg Date: 2015-03-17 15:17 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/5cb7831aea2e Added tag jtreg4.1-b11 for changeset 04f40c388713 ! .hgtags From jonathan.gibbons at oracle.com Fri Mar 20 22:26:46 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 20 Mar 2015 22:26:46 +0000 Subject: hg: code-tools/jtreg: 7901353: testng report is written to the wrong place in multirun mode Message-ID: <201503202226.t2KMQkIO000479@aojmv0008> Changeset: 8d0253171ac6 Author: jjg Date: 2015-03-20 15:26 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/8d0253171ac6 7901353: testng report is written to the wrong place in multirun mode ! src/share/classes/com/sun/javatest/regtest/Main.java ! src/share/classes/com/sun/javatest/regtest/RegressionReporter.java From jonathan.gibbons at oracle.com Fri Mar 20 22:53:10 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 20 Mar 2015 22:53:10 +0000 Subject: hg: code-tools/jtreg: 7901351: Order of execution of tests in a multi-run should be consistent Message-ID: <201503202253.t2KMrGPB007214@aojmv0008> Changeset: aacfe8e799c1 Author: jjg Date: 2015-03-20 15:52 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/aacfe8e799c1 7901351: Order of execution of tests in a multi-run should be consistent ! src/share/classes/com/sun/javatest/regtest/TestManager.java From jonathan.gibbons at oracle.com Fri Mar 20 23:20:27 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 20 Mar 2015 23:20:27 +0000 Subject: hg: code-tools/jtreg: 7901352: jtreg -help verbose does not list multirun Message-ID: <201503202320.t2KNKRvW012963@aojmv0008> Changeset: fb315ed320c6 Author: jjg Date: 2015-03-20 16:20 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/fb315ed320c6 7901352: jtreg -help verbose does not list multirun ! src/share/classes/com/sun/javatest/regtest/Main.java ! src/share/classes/com/sun/javatest/regtest/Verbose.java ! src/share/classes/com/sun/javatest/regtest/i18n.properties From jonathan.gibbons at oracle.com Fri Mar 20 23:26:20 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 20 Mar 2015 23:26:20 +0000 Subject: hg: code-tools/jtreg: Move badly placed import Message-ID: <201503202326.t2KNQKqc014359@aojmv0008> Changeset: 490d2980e330 Author: jjg Date: 2015-03-20 16:26 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/490d2980e330 Move badly placed import ! src/share/classes/com/sun/javatest/regtest/Agent.java From jonathan.gibbons at oracle.com Fri Mar 20 23:42:17 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 20 Mar 2015 23:42:17 +0000 Subject: hg: code-tools/jtreg: fix NPE Message-ID: <201503202342.t2KNgHdY017174@aojmv0008> Changeset: 6b2c073270ea Author: jjg Date: 2015-03-20 16:42 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/6b2c073270ea fix NPE ! src/share/classes/com/sun/javatest/regtest/Main.java From jonathan.gibbons at oracle.com Fri Mar 20 23:53:59 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 20 Mar 2015 23:53:59 +0000 Subject: hg: code-tools/jtreg: 7901354: Agent.main should be moved to AgentServer.main Message-ID: <201503202353.t2KNrx07019348@aojmv0008> Changeset: 91c46967dcdb Author: jjg Date: 2015-03-20 16:53 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/91c46967dcdb 7901354: Agent.main should be moved to AgentServer.main ! src/share/classes/com/sun/javatest/regtest/Agent.java ! src/share/classes/com/sun/javatest/regtest/agent/AgentServer.java From jonathan.gibbons at oracle.com Mon Mar 23 22:39:26 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 23 Mar 2015 22:39:26 +0000 Subject: hg: code-tools/jtreg: Simplification and cleanup of Agent setup Message-ID: <201503232239.t2NMdQHd008390@aojmv0008> Changeset: ff3f20603dec Author: jjg Date: 2015-03-23 15:39 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/ff3f20603dec Simplification and cleanup of Agent setup ! src/share/classes/com/sun/javatest/regtest/Agent.java ! src/share/classes/com/sun/javatest/regtest/CompileAction.java ! src/share/classes/com/sun/javatest/regtest/MainAction.java ! src/share/classes/com/sun/javatest/regtest/RegressionScript.java From jonathan.gibbons at oracle.com Tue Mar 24 18:50:44 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 24 Mar 2015 18:50:44 +0000 Subject: hg: code-tools/jtreg: 7901355: Support new version string scheme Message-ID: <201503241850.t2OIoi4G012305@aojmv0008> Changeset: 003f615a8ef7 Author: jjg Date: 2015-03-24 11:50 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/003f615a8ef7 7901355: Support new version string scheme ! src/share/classes/com/sun/javatest/regtest/agent/JDK_Version.java From jvanek at redhat.com Thu Mar 26 07:46:34 2015 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 26 Mar 2015 08:46:34 +0100 Subject: [rfc] make test ignored or valid only for specific JDK Message-ID: <5513B95A.2060301@redhat.com> Hello! I'm maintaining few thousand tests for various jdks (generally jdk 1.5-jdk 9) . However, current workarounds about which test is valid for which jdk are insufficient. I came to conclusion, that some kind of @validfor-jdk-version or @validfor or @ignoredfor or enhancing of @ignore would solve my issues. Currentl I'm inklining to @validfor or @validfor-version as (currently (with this 7years history)) it is not necessary to distinguish anything else then java.version. My suggested format will be white-chars separated list of conditions with control words of = < > <= >= followed by version string and with evaluation based on version sort and on or between predicates So eg: @validfor <=1.6 >1.7 =1.4.2 If java.version will not be valid for any of predicate then the test will be handled in same way as if @ignore is specified. If it is valid, or annotation missing at all, test will be normally proceed. Do you think enhancement like this is acceptable? If so ,I will prepare webrew soon, and will post it for review. Thank you! J. From jonathan.gibbons at oracle.com Thu Mar 26 18:18:48 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 Mar 2015 11:18:48 -0700 Subject: [rfc] make test ignored or valid only for specific JDK In-Reply-To: <5513B95A.2060301@redhat.com> References: <5513B95A.2060301@redhat.com> Message-ID: <55144D88.3060600@oracle.com> Jiri, I presume you are talking about a set of tests that is distinct from any of the jtreg test suites in an OpenJDK forest, such as langtools/test, jdk/test, etc. Those test suites are tied to the code in the overall forest, and so are inherently versioned without any additional notation. There are a variety of existing mechanisms you could use to address this problem, without adding any new features. 1. Use test lists. You can keep lists identifying which tests are valid in each version, and then specify files containing those lists on the command line with the "@file" mechanism 2. Use exclude lists. You can keep lists identifying which tests are /not/ valid in each version, and then specify files containing those lists on the command line with the "-exclude file" mechanism 3. Keywords. You can tag individual tests with any keywords you choose to use, as long as you also declare the overall set of valid keywords in the TEST.ROOT file. You can filter the set of tests to be executed with the "-k expr" command line option. 4. @requires. This is a relatively new feature. You can put a declarative tag in a test description of the form "@requires expr" where there is a variety of terminals, of which jdk.version is but one. So you could add a line like @requires jdk.version <=1.6 || jdk.version >1.7 || jdk.version = "1.4.2" Not as compact as your proposal, but it exists today. -- Jon On 03/26/2015 12:46 AM, Jiri Vanek wrote: > Hello! > > I'm maintaining few thousand tests for various jdks (generally jdk > 1.5-jdk 9) . However, current workarounds about which test is valid > for which jdk are insufficient. > > I came to conclusion, that some kind of @validfor-jdk-version or > @validfor or @ignoredfor or enhancing of @ignore would solve my issues. > > Currentl I'm inklining to @validfor or @validfor-version as > (currently (with this 7years history)) it is not necessary to > distinguish anything else then java.version. My suggested format will > be white-chars separated list of conditions with control words of = < > > <= >= followed by version string and with evaluation based on > version sort and on or between predicates > > So eg: > @validfor <=1.6 >1.7 =1.4.2 > > If java.version will not be valid for any of predicate then the test > will be handled in same way as if @ignore is specified. If it is > valid, or annotation missing at all, test will be normally proceed. > > Do you think enhancement like this is acceptable? > > If so ,I will prepare webrew soon, and will post it for review. > > Thank you! > > J. From jvanek at redhat.com Mon Mar 30 11:25:09 2015 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 30 Mar 2015 13:25:09 +0200 Subject: [rfc] make test ignored or valid only for specific JDK In-Reply-To: <55144D88.3060600@oracle.com> References: <5513B95A.2060301@redhat.com> <55144D88.3060600@oracle.com> Message-ID: <55193295.6000504@redhat.com> On 03/26/2015 07:18 PM, Jonathan Gibbons wrote: > Jiri, > > I presume you are talking about a set of tests that is distinct from any of the jtreg test suites in Sure :) > an OpenJDK forest, such as langtools/test, jdk/test, etc. Those test suites are tied to the code > in the overall forest, and so are inherently versioned without any additional notation. > > There are a variety of existing mechanisms you could use to address this problem, without adding any > new features. > > 1. Use test lists. You can keep lists identifying which tests are valid in each version, and then > specify files containing those lists on the command line with the "@file" mechanism > > 2. Use exclude lists. You can keep lists identifying which tests are /not/ valid in each version, > and then specify files containing those lists on the command line with the "-exclude file" mechanism > Both above have the same maintenance burden as various copies. > 3. Keywords. You can tag individual tests with any keywords you choose to use, as long as you also > declare the overall set of valid keywords in the TEST.ROOT file. You can filter the set of tests > to be executed with the "-k expr" command line option. Yes keywords are pretty close, and were elaborated. However.. needs some settings on launcher side, and so didn't fit. > > 4. @requires. This is a relatively new feature. You can put a declarative tag in a test description Ok I did not know this one. > of the form "@requires expr" where there is a variety of terminals, of which jdk.version is but > one. So you could add a line like > @requires jdk.version <=1.6 || jdk.version >1.7 || jdk.version = "1.4.2" > Not as compact as your proposal, but it exists today. Well, those looks awesome. I will definitely try. I guess they will work as desired. Thank you very much for your time and complex reply. Best regards from CZ J. > > -- Jon > > On 03/26/2015 12:46 AM, Jiri Vanek wrote: >> Hello! >> >> I'm maintaining few thousand tests for various jdks (generally jdk 1.5-jdk 9) . However, current >> workarounds about which test is valid for which jdk are insufficient. >> >> I came to conclusion, that some kind of @validfor-jdk-version or @validfor or @ignoredfor or >> enhancing of @ignore would solve my issues. >> >> Currentl I'm inklining to @validfor or @validfor-version as (currently (with this 7years >> history)) it is not necessary to distinguish anything else then java.version. My suggested format >> will be white-chars separated list of conditions with control words of = < > <= >= followed by >> version string and with evaluation based on version sort and on or between predicates >> >> So eg: >> @validfor <=1.6 >1.7 =1.4.2 >> >> If java.version will not be valid for any of predicate then the test will be handled in same way >> as if @ignore is specified. If it is valid, or annotation missing at all, test will be normally >> proceed. >> >> Do you think enhancement like this is acceptable? >> >> If so ,I will prepare webrew soon, and will post it for review. >> >> Thank you! >> >> J. > From jvanek at redhat.com Mon Mar 30 13:51:42 2015 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 30 Mar 2015 15:51:42 +0200 Subject: [rfc] make test ignored or valid only for specific JDK In-Reply-To: <55193295.6000504@redhat.com> References: <5513B95A.2060301@redhat.com> <55144D88.3060600@oracle.com> <55193295.6000504@redhat.com> Message-ID: <551954EE.9070802@redhat.com> On 03/30/2015 01:25 PM, Jiri Vanek wrote: > On 03/26/2015 07:18 PM, Jonathan Gibbons wrote: >> Jiri, >> >> I presume you are talking about a set of tests that is distinct from any of the jtreg test suites in > > Sure :) > >> an OpenJDK forest, such as langtools/test, jdk/test, etc. Those test suites are tied to the code >> in the overall forest, and so are inherently versioned without any additional notation. >> >> There are a variety of existing mechanisms you could use to address this problem, without adding any >> new features. >> >> 1. Use test lists. You can keep lists identifying which tests are valid in each version, and then >> specify files containing those lists on the command line with the "@file" mechanism >> >> 2. Use exclude lists. You can keep lists identifying which tests are /not/ valid in each version, >> and then specify files containing those lists on the command line with the "-exclude file" mechanism >> > > Both above have the same maintenance burden as various copies. > >> 3. Keywords. You can tag individual tests with any keywords you choose to use, as long as you also >> declare the overall set of valid keywords in the TEST.ROOT file. You can filter the set of tests >> to be executed with the "-k expr" command line option. > > Yes keywords are pretty close, and were elaborated. However.. needs some settings on launcher side, > and so didn't fit. > >> >> 4. @requires. This is a relatively new feature. You can put a declarative tag in a test description > > Ok I did not know this one. >> of the form "@requires expr" where there is a variety of terminals, of which jdk.version is but >> one. So you could add a line like >> @requires jdk.version <=1.6 || jdk.version >1.7 || jdk.version = "1.4.2" >> Not as compact as your proposal, but it exists today. hmhm. It does not seem to be working as "advertised": * @requires jdk.version <= 1.7 leads to : test result: Error. Parse Exception: Syntax error in @requires expression: unrecognized character: `.' * @requires jdk.version <= 7 leads to test result: Error. Error evaluating expression: invalid numeric value: 1.8 Is it expected bahviour? I tried also with various spaces/nospace.... J. > > > Well, those looks awesome. I will definitely try. I guess they will work as desired. > > Thank you very much for your time and complex reply. > > Best regards from CZ > J. > >> >> -- Jon >> >> On 03/26/2015 12:46 AM, Jiri Vanek wrote: >>> Hello! >>> >>> I'm maintaining few thousand tests for various jdks (generally jdk 1.5-jdk 9) . However, current >>> workarounds about which test is valid for which jdk are insufficient. >>> >>> I came to conclusion, that some kind of @validfor-jdk-version or @validfor or @ignoredfor or >>> enhancing of @ignore would solve my issues. >>> >>> Currentl I'm inklining to @validfor or @validfor-version as (currently (with this 7years >>> history)) it is not necessary to distinguish anything else then java.version. My suggested format >>> will be white-chars separated list of conditions with control words of = < > <= >= followed by >>> version string and with evaluation based on version sort and on or between predicates >>> >>> So eg: >>> @validfor <=1.6 >1.7 =1.4.2 >>> >>> If java.version will not be valid for any of predicate then the test will be handled in same way >>> as if @ignore is specified. If it is valid, or annotation missing at all, test will be normally >>> proceed. >>> >>> Do you think enhancement like this is acceptable? >>> >>> If so ,I will prepare webrew soon, and will post it for review. >>> >>> Thank you! >>> >>> J. >> > From jonathan.gibbons at oracle.com Tue Mar 31 00:56:33 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 31 Mar 2015 00:56:33 +0000 Subject: hg: code-tools/jtreg: Improved asmtools handling Message-ID: <201503310056.t2V0uXXj021659@aojmv0008> Changeset: e88738b571de Author: jjg Date: 2015-03-30 17:56 -0700 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/e88738b571de Improved asmtools handling ! src/share/classes/com/sun/javatest/regtest/ActionRecorder.java ! src/share/classes/com/sun/javatest/regtest/CompileAction.java ! src/share/classes/com/sun/javatest/regtest/Main.java ! src/share/classes/com/sun/javatest/regtest/RegressionParameters.java ! src/share/classes/com/sun/javatest/regtest/RegressionScript.java