From jonathan.gibbons at oracle.com Thu Feb 1 23:31:41 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 01 Feb 2018 23:31:41 +0000 Subject: hg: code-tools/jtreg: 7902103: Can't display test files if running with 'jtreg -gui' Message-ID: <201802012331.w11NVfwZ007352@aojmv0008.oracle.com> Changeset: f7be266f79b4 Author: jjg Date: 2018-02-01 15:27 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/f7be266f79b4 7902103: Can't display test files if running with 'jtreg -gui' ! src/share/classes/com/sun/javatest/regtest/config/RegressionParameters.java ! src/share/classes/com/sun/javatest/regtest/config/RegressionTestSuite.java ! src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java ! src/share/classes/com/sun/javatest/regtest/tool/Tool.java ! src/share/classes/com/sun/javatest/regtest/tool/i18n.properties ! test/basic/Basic.java From jonathan.gibbons at oracle.com Mon Feb 5 23:27:45 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 05 Feb 2018 23:27:45 +0000 Subject: hg: code-tools/jtreg: fix issues displaying jtreg splash screen in gui mode Message-ID: <201802052327.w15NRkcU023527@aojmv0008.oracle.com> Changeset: 2704bf642146 Author: jjg Date: 2018-02-05 15:23 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/2704bf642146 fix issues displaying jtreg splash screen in gui mode ! make/Rules.gmk ! make/jtreg.gmk + src/share/classes/com/sun/javatest/regtest/tool/Startup.java ! src/share/classes/com/sun/javatest/regtest/tool/Tool.java + src/share/classes/com/sun/javatest/regtest/tool/jtlogo.gif From jonathan.gibbons at oracle.com Tue Feb 6 01:07:30 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 06 Feb 2018 01:07:30 +0000 Subject: hg: code-tools/jtreg: 7902090: Update JDK_Version to be more future-proof Message-ID: <201802060107.w1617ULd003974@aojmv0008.oracle.com> Changeset: 34702ed26bcd Author: jjg Date: 2018-02-05 17:03 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/34702ed26bcd 7902090: Update JDK_Version to be more future-proof ! src/share/classes/com/sun/javatest/regtest/agent/JDK_Version.java ! src/share/classes/com/sun/javatest/regtest/config/RegressionContext.java ! src/share/classes/com/sun/javatest/regtest/tool/Tool.java From jvanek at redhat.com Tue Feb 6 10:54:10 2018 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 6 Feb 2018 11:54:10 +0100 Subject: RFC: add starred module(s) In-Reply-To: <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> Message-ID: Hi guys! Thank you for all you detailed answers. Really appreciated. We created generator of @module tag from javac+java output to workaround it. Is there possible desire to include something like it into jtreg itself? Thanx again! J. On 12/20/2017 06:27 PM, Jonathan Gibbons wrote: > > > On 12/20/17 9:14 AM, Jiri Vanek wrote: >> On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: >>> Hi. >>> >>> I just wanted to commend on enhancing JTreg to automatically calculate module dependencies. Yes, >>> compiler knows the direct static dependencies of the compiler code, but that is not all that is >>> needed to be known. @module annotation is used for a few not completely related things. Besides >>> requesting "--add-exports?, it can also request "--add-opens" and it can influence test selection >>> during execution. Of this three usages, only one could be covered by static dependency analysis. >>> >> >> >> Thank you very much for this input! >> >> From what you are saying, the need for more support of @module-whatever is needed - and doable. >> Current @modules is adding --add-exports and --add-opens? of the modules you specified to the >> command. >> If there will be way to add exports and opens of those, which can be covered by static analyse, >> then it will be already more then helpfull! Especially if you will be able to add some more manually. >> Of course more granular support like @modules-export and @modules-opens and similar would be nice, >> but Thats more far away from this proposal. >> >> J. > > Jiri, > > To be clear ... it is not reasonable to add such support for an enhanced @modules for use at the > time the test is selected for execution and then subsequently executed.? If nothing else, there is a > big chicken-and-egg problem here? ... you cannot analyse the test code until it has been compiled, > and you cannot compile it until you know the module dependencies. > > In general, for existing JDK tests, the @modules have been determined. For new tests, I recommend > you look to your IDE or other development-time tools, to help determine the dependencies of the test > code, and then record the results in an @modules tag in the test description. > > -- Jon > >> >>> >>>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >>>> >>>> Hi Jonathan! >>>> >>>> Thank you very much for great answer. Few remarks inline. >>>> >>>> >>>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>>>> Jiri, Mila, >>>>> There are three significant questions here. >>>>> 1. @modules all-needed >>>>> This is a non-starter. @modules participates in a relatively light-weight test selection mechanism >>>> >>>> Sure. It is last step, if it will be ever started. >>>> >>>>> ... i.e. tests are not selected if the specified modules are not available in the system image. >>>>> Having jtreg analyse the source code to determine the set of necessary modules is just not >>>>> practical. >>>>> 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* >>>>> Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It >>>>> requires that we can list the (internal) packages of a module. Yes, there may be a attribute >>>>> that provides the info, but the attribute is not guaranteed to be available, and if it's not, >>>>> you're >>>> terrible truth. see at bottom. >>>> >>>>> reduced to scanning the module contents.? On the desirability point of view, the use of this >>>>> sort of syntax was discussed, and rejected, for module declarations, and while that is separate >>>>> from what is >>>> >>>> I was reading most of this discussion, and I can agree with it for final deployment, but not for >>>> testing. >>>>> proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for >>>>> the Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for >>>>> those options. >>>> >>>> This is probably the only sentence I moreover disagree with you. Jtreg is far away fro being >>>> tinny wrapper, and it always did huge help for tests authors.? So helping testers with setting >>>> up module path a bit, may be good step. >>>>> One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just >>>>> having a single @modules directive with many arg values, possibly spanning many lines, as in ... >>>>> ?? * .... >>>>> ?? * @modules java.security.jgss/sun.security.krb5.internal >>>>> ?? * java.security.jgss/sun.security.krb5.internal.ccache >>>>> ?? * java.security.jgss/sun.security.krb5.internal.crypto >>>>> ?? * java.security.jgss/sun.security.krb5.internal.ktab >>>>> ?? * java.base/sun.security.util >>>>> ?? * java.security.jgss/sun.security.jgss >>>> >>>> Still you need to enumerate them all. That mean to run javac and jmod in loops? one by one, >>>> untill you get collect them. >>>>> 3. Shell scripts. >>>>> Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we >>>>> have made efforts to convert many/most JDK shell tests to Java code. The general experience was >>>>> that such tests were very fragile, and were often wrong/broken. They typically execute slower >>>>> than equivalent Java code, especially when using libraries providing commonly-used or >>>>> domain-specific functionality. >>>> >>>> Well, shell lunchers have theirs dark sides, thats right. But are awesome feature without >>>> replacement. >>>>> And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if >>>>> present for JDK 8 tests). >>>> >>>> Its a bug :) >>>>> When using Java code instead of shell scripts, you can look to libraries in the various test >>>>> suites for suggestions on useful methods to provide, such as invoking generating and compiling >>>>> source code, providing simple equivalents for regex search (simple grep), comparison (simple >>>>> diff), etc, as well as support for running subprocesses when necessary. One common pattern is >>>>> to use Java code to validate whether it is appropriate to run a test in the current >>>>> configuration and to then launch a JVM with a selected combination of options. This sort of >>>>> mode has explicit support in jtreg:? "@run driver" is similar to "@run main" for running a >>>>> class, but it is not run with any JVM options intended for test JVMs. This makes it suitable >>>>> for running "test driver" classes which spawn JVMs to run the "real" test code.? And if you're >>>>> just writing API tests, then I recommend using plain old Java code and "agentvm" mode to have >>>>> the tests as fast as possible. >>>> >>>> >>>> You are mostly right. But consider this: The locating of modules is painful when you are dealing >>>> with private apis. And that is what you do in jtregs for half of the time... >>>> So naturally, the help would be easy. >>>> On contrary, the help do not come from JDK itself in any "supported" way (or am I missing >>>> something?) >>>> Still the javac can do so. So it would be natural to enahnce javac to help with this a bit more >>>> via some more solid api. Maybe you know something here? >>>> >>>> One would say, that writing private api jtreg is one or two modules usage only. Unluckily, >>>> oposite is true, and Mila's * idea is another proof of it. And If I look to past to my recent >>>> work, I was facing the same. Just got angry later. >>>> >>>> >>>> So generally - some help should be provided in JDK to deal with it. And as JDK looks to have its >>>> reasons to not to do so, Jtregs should. >>>> >>>> >>>> Thanx for again for your reply! >>>> ? J. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From jvanek at redhat.com Tue Feb 6 10:55:24 2018 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 6 Feb 2018 11:55:24 +0100 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: <991930f2-0f30-f8c5-179a-8f9b12c8b4e0@redhat.com> References: <991930f2-0f30-f8c5-179a-8f9b12c8b4e0@redhat.com> Message-ID: <693d59ee-bc3e-1aae-fc26-2f591c2641cf@redhat.com> On 12/20/2017 05:35 PM, Jiri Vanek wrote: > On 12/15/2017 11:37 AM, Miloslav Zezulka wrote: >> This is a very small patch fixing the issue pointed out in $subject. I've >> added checks for both compile and test JDK - is this an overkill, since >> most of the time the implication goes COMPILEJDK.modular => >> TESTJDK.modular, or a necessary thing to have for foolproofness? > ping? > > Works fine. Johnatan, can you push it? Or do you wont mila to create regular webrev? Is there some > place to add test for it? > > Tahnx a lot! > ? J. > > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From weijun.wang at oracle.com Tue Feb 6 13:51:27 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 6 Feb 2018 21:51:27 +0800 Subject: RFC: add starred module(s) In-Reply-To: References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> Message-ID: <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> While I am not requesting for an automatic discovery of @module tags, I wonder if we can enhance jtreg from another angle to make test writing a little easier. The "@modules java.security.jgss/sun.security.krb5.*" example is painful because these --add-exports are not required by the tests themselves. Instead, it's a library class (KDC.java in the same directory) they are using that is accessing these internal classes. This explains why the @module tags appear in multiple tests but you won't see any of these tests importing a class in those packages. Think of this extreme example, suppose someone adds a reference to an internal class in ProcessTools.java, then suddenly all tests using it require a new @module tag. So, is it possible to add the @module tags to that library class? /* * @library * @module .... */ Thanks Max From jonathan.gibbons at oracle.com Tue Feb 6 16:36:01 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 6 Feb 2018 08:36:01 -0800 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: <693d59ee-bc3e-1aae-fc26-2f591c2641cf@redhat.com> References: <991930f2-0f30-f8c5-179a-8f9b12c8b4e0@redhat.com> <693d59ee-bc3e-1aae-fc26-2f591c2641cf@redhat.com> Message-ID: <749386dd-45a9-0683-3ef8-34d44055c341@oracle.com> Jiri, Mila, I wonder why the fix is necessary. TESTMODULES contains a property of the test description (the @modules entry).? The env variable will not be set if the value is empty. So, given that (versions of) test suites are generally specific to a version of the JDK, I wonder why you are trying to run tests with @module entries on a non-modular JDK. And, if there is a plausible test case for such tests, the fix is arguably incomplete, because the TEST* environment variables for shell tests mirror the test.* system properties for Java tests. I think a better direction would be to warn against the use of @modules on a non-modular JDK. -- Jon On 2/6/18 2:55 AM, Jiri Vanek wrote: > On 12/20/2017 05:35 PM, Jiri Vanek wrote: >> On 12/15/2017 11:37 AM, Miloslav Zezulka wrote: >>> This is a very small patch fixing the issue pointed out in $subject. >>> I've >>> added checks for both compile and test JDK - is this an overkill, since >>> most of the time the implication goes COMPILEJDK.modular => >>> TESTJDK.modular, or a necessary thing to have for foolproofness? >> > ping? >> >> Works fine. Johnatan, can you push it? Or do you wont mila to create >> regular webrev? Is there some place to add test for it? >> >> Tahnx a lot! >> ?? J. >> >> > > From jonathan.gibbons at oracle.com Tue Feb 6 22:47:28 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 06 Feb 2018 22:47:28 +0000 Subject: hg: code-tools/jtreg: Add basic support for Help>About jtreg Message-ID: <201802062247.w16MlTMf004814@aojmv0008.oracle.com> Changeset: 556cf0953931 Author: jjg Date: 2018-02-06 14:42 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/556cf0953931 Add basic support for Help>About jtreg ! make/Rules.gmk ! make/jtreg.gmk ! src/share/classes/com/sun/javatest/regtest/config/RegressionTestSuite.java + src/share/classes/com/sun/javatest/regtest/tool/RegressionContextManager.java ! src/share/classes/com/sun/javatest/regtest/tool/Tool.java - src/share/classes/com/sun/javatest/regtest/tool/jtlogo.gif + src/share/classes/com/sun/javatest/regtest/tool/jtlogo.png From felix.yang at oracle.com Wed Feb 7 01:51:56 2018 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 7 Feb 2018 09:51:56 +0800 Subject: RFC: add starred module(s) In-Reply-To: <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> Message-ID: <8e98de34-3ea8-0497-47ef-9867dbd50bab@oracle.com> Hi Max, ??? I have another idea, how about make the test libs into JPMS modules. Then the dependencies will be explicitly described at where it happens. Any comment? -Felix On 2018/2/6 21:51, Weijun Wang wrote: > While I am not requesting for an automatic discovery of @module tags, I wonder if we can enhance jtreg from another angle to make test writing a little easier. > > The "@modules java.security.jgss/sun.security.krb5.*" example is painful because these --add-exports are not required by the tests themselves. Instead, it's a library class (KDC.java in the same directory) they are using that is accessing these internal classes. This explains why the @module tags appear in multiple tests but you won't see any of these tests importing a class in those packages. > > Think of this extreme example, suppose someone adds a reference to an internal class in ProcessTools.java, then suddenly all tests using it require a new @module tag. > > So, is it possible to add the @module tags to that library class? > > /* > * @library > * @module .... > */ > > Thanks > Max > From weijun.wang at oracle.com Wed Feb 7 05:38:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Feb 2018 13:38:17 +0800 Subject: RFC: add starred module(s) In-Reply-To: <8e98de34-3ea8-0497-47ef-9867dbd50bab@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> <8e98de34-3ea8-0497-47ef-9867dbd50bab@oracle.com> Message-ID: <3511608F-107C-4FF9-A7E2-09EEE9E825A5@oracle.com> > On Feb 7, 2018, at 9:51 AM, Felix Yang wrote: > > Hi Max, > > I have another idea, how about make the test libs into JPMS modules. Then the dependencies will be explicitly described at where it happens. Any comment? Your proposed change seems too big to me, and I'm not sure how to do it, and the size of a module, etc. --Max > > -Felix > On 2018/2/6 21:51, Weijun Wang wrote: >> While I am not requesting for an automatic discovery of @module tags, I wonder if we can enhance jtreg from another angle to make test writing a little easier. >> >> The "@modules java.security.jgss/sun.security.krb5.*" example is painful because these --add-exports are not required by the tests themselves. Instead, it's a library class (KDC.java in the same directory) they are using that is accessing these internal classes. This explains why the @module tags appear in multiple tests but you won't see any of these tests importing a class in those packages. >> >> Think of this extreme example, suppose someone adds a reference to an internal class in ProcessTools.java, then suddenly all tests using it require a new @module tag. >> >> So, is it possible to add the @module tags to that library class? >> >> /* >> * @library >> * @module .... >> */ >> >> Thanks >> Max >> > From jvanek at redhat.com Wed Feb 7 10:36:01 2018 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 7 Feb 2018 11:36:01 +0100 Subject: RFC: add starred module(s) In-Reply-To: <3511608F-107C-4FF9-A7E2-09EEE9E825A5@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> <8e98de34-3ea8-0497-47ef-9867dbd50bab@oracle.com> <3511608F-107C-4FF9-A7E2-09EEE9E825A5@oracle.com> Message-ID: <8c4d969f-083e-c4df-e96a-80da98909d3b@redhat.com> On 02/07/2018 06:38 AM, Weijun Wang wrote: > > >> On Feb 7, 2018, at 9:51 AM, Felix Yang wrote: >> >> Hi Max, >> >> I have another idea, how about make the test libs into JPMS modules. Then the dependencies will be explicitly described at where it happens. Any comment? > > Your proposed change seems too big to me, and I'm not sure how to do it, and the size of a module, etc. > This would be hardly compatible with older jdk, wouldnt it? > --Max > >> >> -Felix >> On 2018/2/6 21:51, Weijun Wang wrote: >>> While I am not requesting for an automatic discovery of @module tags, I wonder if we can enhance jtreg from another angle to make test writing a little easier. >>> >>> The "@modules java.security.jgss/sun.security.krb5.*" example is painful because these --add-exports are not required by the tests themselves. Instead, it's a library class (KDC.java in the same directory) they are using that is accessing these internal classes. This explains why the @module tags appear in multiple tests but you won't see any of these tests importing a class in those packages. >>> >>> Think of this extreme example, suppose someone adds a reference to an internal class in ProcessTools.java, then suddenly all tests using it require a new @module tag. >>> >>> So, is it possible to add the @module tags to that library class? >>> >>> /* >>> * @library >>> * @module .... >>> */ >>> >>> Thanks >>> Max >>> >> > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From mzezulka at redhat.com Wed Feb 7 14:09:07 2018 From: mzezulka at redhat.com (Miloslav Zezulka) Date: Wed, 7 Feb 2018 15:09:07 +0100 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: <749386dd-45a9-0683-3ef8-34d44055c341@oracle.com> References: <991930f2-0f30-f8c5-179a-8f9b12c8b4e0@redhat.com> <693d59ee-bc3e-1aae-fc26-2f591c2641cf@redhat.com> <749386dd-45a9-0683-3ef8-34d44055c341@oracle.com> Message-ID: Hello Jonathan, > So, given that (versions of) test suites are generally specific to a version of the JDK... That is correct for most of the test cases. However, there could be (and are in the reproducers we work with) tests common for non-modular and modular JDKs which are based on this scenario: Test123.java Test123.sh <- jtreg test which calls javac and java of Test123 So. to avoid copy and pasting the same test for different JDKs, it would be nicer to rely on the fact that the TESTMODULES property will not be exported for non-modular ones. Of course, we could also rewrite all the shell tests to the point when they would not require shell jtregs whatsoever, but my suggested solution would require very few changes to the already existing tests (and would not enforce copy and pasting). It is also worth mentioning that this "hack" already works with Java jtregs where it is possible to run tests, containing @modules entry, with a non-modular JDK. > And, if there is a plausible test case for such tests, the fix is arguably incomplete, because the TEST* environment variables for shell > tests mirror the test.* system properties for Java tests. I guess you are right. Attached is the script which deals with the root cause. On Tue, Feb 6, 2018 at 5:36 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Jiri, Mila, > > I wonder why the fix is necessary. > > TESTMODULES contains a property of the test description (the @modules > entry). The env variable will not be set if the value is empty. > > So, given that (versions of) test suites are generally specific to a > version of the JDK, I wonder why you are trying to run tests with @module > entries on a non-modular JDK. > > And, if there is a plausible test case for such tests, the fix is arguably > incomplete, because the TEST* environment variables for shell tests mirror > the test.* system properties for Java tests. > > I think a better direction would be to warn against the use of @modules on > a non-modular JDK. > > -- Jon > > > On 2/6/18 2:55 AM, Jiri Vanek wrote: > >> On 12/20/2017 05:35 PM, Jiri Vanek wrote: >> >>> On 12/15/2017 11:37 AM, Miloslav Zezulka wrote: >>> >>>> This is a very small patch fixing the issue pointed out in $subject. >>>> I've >>>> added checks for both compile and test JDK - is this an overkill, since >>>> most of the time the implication goes COMPILEJDK.modular => >>>> TESTJDK.modular, or a necessary thing to have for foolproofness? >>>> >>> >>> ping? >> >>> >>> Works fine. Johnatan, can you push it? Or do you wont mila to create >>> regular webrev? Is there some place to add test for it? >>> >>> Tahnx a lot! >>> J. >>> >>> >>> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: testmodulesenv.patch Type: text/x-patch Size: 729 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Wed Feb 7 16:14:54 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 7 Feb 2018 08:14:54 -0800 Subject: RFC: add starred module(s) In-Reply-To: References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> Message-ID: Jiri, I would not expect to see functionality like this available while tests are running. It might be reasonable to provide it as a separate utility, such that a test author can run it, and decide whether to incorporate or augment the output from such a utility in the test code, in the same way that import statements are not inferred by javac, but can be generated by an IDE. -- Jon On 2/6/18 2:54 AM, Jiri Vanek wrote: > Hi guys! > > Thank you for all you detailed answers. Really appreciated. > We created generator of @module tag from javac+java output to > workaround it. > > Is there possible desire to include something like it into jtreg itself? > > Thanx again! > ? J. > On 12/20/2017 06:27 PM, Jonathan Gibbons wrote: >> >> >> On 12/20/17 9:14 AM, Jiri Vanek wrote: >>> On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: >>>> Hi. >>>> >>>> I just wanted to commend on enhancing JTreg to automatically >>>> calculate module dependencies. Yes, compiler knows the direct >>>> static dependencies of the compiler code, but that is not all that >>>> is needed to be known. @module annotation is used for a few not >>>> completely related things. Besides requesting "--add-exports?, it >>>> can also request "--add-opens" and it can influence test selection >>>> during execution. Of this three usages, only one could be covered >>>> by static dependency analysis. >>>> >>> >>> >>> Thank you very much for this input! >>> >>> From what you are saying, the need for more support of >>> @module-whatever is needed - and doable. >>> Current @modules is adding --add-exports and --add-opens? of the >>> modules you specified to the? command. >>> If there will be way to add exports and opens of those, which can be >>> covered by static analyse, then it will be already more then >>> helpfull! Especially if you will be able to add some more manually. >>> Of course more granular support like @modules-export and >>> @modules-opens and similar would be nice, but Thats more far away >>> from this proposal. >>> >>> J. >> >> Jiri, >> >> To be clear ... it is not reasonable to add such support for an >> enhanced @modules for use at the time the test is selected for >> execution and then subsequently executed.? If nothing else, there is >> a big chicken-and-egg problem here? ... you cannot analyse the test >> code until it has been compiled, and you cannot compile it until you >> know the module dependencies. >> >> In general, for existing JDK tests, the @modules have been >> determined. For new tests, I recommend you look to your IDE or other >> development-time tools, to help determine the dependencies of the >> test code, and then record the results in an @modules tag in the test >> description. >> >> -- Jon >> >>> >>>> >>>>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >>>>> >>>>> Hi Jonathan! >>>>> >>>>> Thank you very much for great answer. Few remarks inline. >>>>> >>>>> >>>>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>>>>> Jiri, Mila, >>>>>> There are three significant questions here. >>>>>> 1. @modules all-needed >>>>>> This is a non-starter. @modules participates in a relatively >>>>>> light-weight test selection mechanism >>>>> >>>>> Sure. It is last step, if it will be ever started. >>>>> >>>>>> ... i.e. tests are not selected if the specified modules are not >>>>>> available in the system image. Having jtreg analyse the source >>>>>> code to determine the set of necessary modules is just not >>>>>> practical. >>>>>> 2. Starred modules, as in @modules >>>>>> java.security.jgss/sun.security.krb5.internal.* >>>>>> Setting aside whether this is desirable or not, this is not >>>>>> necessarily an easy thing to do. It requires that we can list the >>>>>> (internal) packages of a module. Yes, there may be a attribute >>>>>> that provides the info, but the attribute is not guaranteed to be >>>>>> available, and if it's not, you're >>>>> terrible truth. see at bottom. >>>>> >>>>>> reduced to scanning the module contents.? On the desirability >>>>>> point of view, the use of this sort of syntax was discussed, and >>>>>> rejected, for module declarations, and while that is separate >>>>>> from what is >>>>> >>>>> I was reading most of this discussion, and I can agree with it for >>>>> final deployment, but not for testing. >>>>>> proposed here, it does lend guidance. Neither is the '*' syntax >>>>>> supported by the options for the Java launcher or javac, and this >>>>>> construct is intended to be a thinly-veiled wrapper for those >>>>>> options. >>>>> >>>>> This is probably the only sentence I moreover disagree with you. >>>>> Jtreg is far away fro being tinny wrapper, and it always did huge >>>>> help for tests authors.? So helping testers with setting up module >>>>> path a bit, may be good step. >>>>>> One minor comment ... you can reduce the "wordiness" of your >>>>>> examples by almost 50% by just having a single @modules directive >>>>>> with many arg values, possibly spanning many lines, as in ... >>>>>> ?? * .... >>>>>> ?? * @modules java.security.jgss/sun.security.krb5.internal >>>>>> ?? * java.security.jgss/sun.security.krb5.internal.ccache >>>>>> ?? * java.security.jgss/sun.security.krb5.internal.crypto >>>>>> ?? * java.security.jgss/sun.security.krb5.internal.ktab >>>>>> ?? * java.base/sun.security.util >>>>>> ?? * java.security.jgss/sun.security.jgss >>>>> >>>>> Still you need to enumerate them all. That mean to run javac and >>>>> jmod in loops? one by one, untill you get collect them. >>>>>> 3. Shell scripts. >>>>>> Using shell scripts for jtreg tests is generally discouraged, >>>>>> these days, to the point that we have made efforts to convert >>>>>> many/most JDK shell tests to Java code. The general experience >>>>>> was that such tests were very fragile, and were often >>>>>> wrong/broken. They typically execute slower than equivalent Java >>>>>> code, especially when using libraries providing commonly-used or >>>>>> domain-specific functionality. >>>>> >>>>> Well, shell lunchers have theirs dark sides, thats right. But are >>>>> awesome feature without replacement. >>>>>> And as you note below, processing variables like TESTMODULES is >>>>>> problematic. (It is a bug if present for JDK 8 tests). >>>>> >>>>> Its a bug :) >>>>>> When using Java code instead of shell scripts, you can look to >>>>>> libraries in the various test suites for suggestions on useful >>>>>> methods to provide, such as invoking generating and compiling >>>>>> source code, providing simple equivalents for regex search >>>>>> (simple grep), comparison (simple diff), etc, as well as support >>>>>> for running subprocesses when necessary. One common pattern is to >>>>>> use Java code to validate whether it is appropriate to run a test >>>>>> in the current configuration and to then launch a JVM with a >>>>>> selected combination of options. This sort of mode has explicit >>>>>> support in jtreg:? "@run driver" is similar to "@run main" for >>>>>> running a class, but it is not run with any JVM options intended >>>>>> for test JVMs. This makes it suitable for running "test driver" >>>>>> classes which spawn JVMs to run the "real" test code.? And if >>>>>> you're just writing API tests, then I recommend using plain old >>>>>> Java code and "agentvm" mode to have the tests as fast as possible. >>>>> >>>>> >>>>> You are mostly right. But consider this: The locating of modules >>>>> is painful when you are dealing with private apis. And that is >>>>> what you do in jtregs for half of the time... >>>>> So naturally, the help would be easy. >>>>> On contrary, the help do not come from JDK itself in any >>>>> "supported" way (or am I missing something?) >>>>> Still the javac can do so. So it would be natural to enahnce javac >>>>> to help with this a bit more via some more solid api. Maybe you >>>>> know something here? >>>>> >>>>> One would say, that writing private api jtreg is one or two >>>>> modules usage only. Unluckily, oposite is true, and Mila's * idea >>>>> is another proof of it. And If I look to past to my recent work, I >>>>> was facing the same. Just got angry later. >>>>> >>>>> >>>>> So generally - some help should be provided in JDK to deal with >>>>> it. And as JDK looks to have its reasons to not to do so, Jtregs >>>>> should. >>>>> >>>>> >>>>> Thanx for again for your reply! >>>>> ? J. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From jonathan.gibbons at oracle.com Wed Feb 7 16:21:14 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 7 Feb 2018 08:21:14 -0800 Subject: RFC: add starred module(s) In-Reply-To: <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> Message-ID: <16d7b01c-3b26-b8bc-73c2-3f534fd2957e@oracle.com> Max, This would be a big change for jtreg. The use of library classes has grown significantly over the past couple of years, which is not a bad thing in and of itself, but it does lead to questions about the design of such libraries, and the compatibility concerns for updating such libraries. Making an edit to ProcessTools such that all tests have to be edited might indicate a poor design for ProcessTools. Indeed, we went through such an issue with the langtools "toolbox" library, in which we split the library (a single class with nested classes) into a package of classes, so that additional functionality could be added as needed, in new classes, without affecting existing uses. -- Jon On 2/6/18 5:51 AM, Weijun Wang wrote: > While I am not requesting for an automatic discovery of @module tags, I wonder if we can enhance jtreg from another angle to make test writing a little easier. > > The "@modules java.security.jgss/sun.security.krb5.*" example is painful because these --add-exports are not required by the tests themselves. Instead, it's a library class (KDC.java in the same directory) they are using that is accessing these internal classes. This explains why the @module tags appear in multiple tests but you won't see any of these tests importing a class in those packages. > > Think of this extreme example, suppose someone adds a reference to an internal class in ProcessTools.java, then suddenly all tests using it require a new @module tag. > > So, is it possible to add the @module tags to that library class? > > /* > * @library > * @module .... > */ > > Thanks > Max > From jonathan.gibbons at oracle.com Wed Feb 7 16:23:22 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 7 Feb 2018 08:23:22 -0800 Subject: RFC: add starred module(s) In-Reply-To: <8e98de34-3ea8-0497-47ef-9867dbd50bab@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> <8e98de34-3ea8-0497-47ef-9867dbd50bab@oracle.com> Message-ID: <646719d7-ab51-a9bc-de19-fdb03242d6ea@oracle.com> Felix, Generally, this is not a bad idea. jtreg supports library modules, although I'll be the first to admit there may be rough edges still to be discovered in the support. -- Jon On 2/6/18 5:51 PM, Felix Yang wrote: > Hi Max, > > ??? I have another idea, how about make the test libs into JPMS > modules. Then the dependencies will be explicitly described at where > it happens. Any comment? > > -Felix > On 2018/2/6 21:51, Weijun Wang wrote: >> While I am not requesting for an automatic discovery of @module tags, >> I wonder if we can enhance jtreg from another angle to make test >> writing a little easier. >> >> The "@modules java.security.jgss/sun.security.krb5.*" example is >> painful because these --add-exports are not required by the tests >> themselves. Instead, it's a library class (KDC.java in the same >> directory) they are using that is accessing these internal classes. >> This explains why the @module tags appear in multiple tests but you >> won't see any of these tests importing a class in those packages. >> >> Think of this extreme example, suppose someone adds a reference to an >> internal class in ProcessTools.java, then suddenly all tests using it >> require a new @module tag. >> >> So, is it possible to add the @module tags to that library class? >> >> /* >> ? * @library >> ? * @module .... >> ? */ >> >> Thanks >> Max >> > From jonathan.gibbons at oracle.com Wed Feb 7 16:27:52 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 7 Feb 2018 08:27:52 -0800 Subject: RFC: add starred module(s) In-Reply-To: <3511608F-107C-4FF9-A7E2-09EEE9E825A5@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> <8e98de34-3ea8-0497-47ef-9867dbd50bab@oracle.com> <3511608F-107C-4FF9-A7E2-09EEE9E825A5@oracle.com> Message-ID: Max, It is not unreasonable to use modules for library code, but any such code would require careful design to get the functionality right with reasonable/minimal dependencies. As we have see with some of the existing package-oriented libraries, it is all too easy to end up with a large indivisible interdependent collection of code. -- Jon On 2/6/18 9:38 PM, Weijun Wang wrote: > >> On Feb 7, 2018, at 9:51 AM, Felix Yang wrote: >> >> Hi Max, >> >> I have another idea, how about make the test libs into JPMS modules. Then the dependencies will be explicitly described at where it happens. Any comment? > Your proposed change seems too big to me, and I'm not sure how to do it, and the size of a module, etc. > > --Max > >> -Felix >> On 2018/2/6 21:51, Weijun Wang wrote: >>> While I am not requesting for an automatic discovery of @module tags, I wonder if we can enhance jtreg from another angle to make test writing a little easier. >>> >>> The "@modules java.security.jgss/sun.security.krb5.*" example is painful because these --add-exports are not required by the tests themselves. Instead, it's a library class (KDC.java in the same directory) they are using that is accessing these internal classes. This explains why the @module tags appear in multiple tests but you won't see any of these tests importing a class in those packages. >>> >>> Think of this extreme example, suppose someone adds a reference to an internal class in ProcessTools.java, then suddenly all tests using it require a new @module tag. >>> >>> So, is it possible to add the @module tags to that library class? >>> >>> /* >>> * @library >>> * @module .... >>> */ >>> >>> Thanks >>> Max >>> From jonathan.gibbons at oracle.com Wed Feb 7 16:37:44 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 7 Feb 2018 08:37:44 -0800 Subject: RFC: add starred module(s) In-Reply-To: <8c4d969f-083e-c4df-e96a-80da98909d3b@redhat.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <196C3EA8-FCE9-4910-A455-BD189C3E7986@oracle.com> <8e98de34-3ea8-0497-47ef-9867dbd50bab@oracle.com> <3511608F-107C-4FF9-A7E2-09EEE9E825A5@oracle.com> <8c4d969f-083e-c4df-e96a-80da98909d3b@redhat.com> Message-ID: On 2/7/18 2:36 AM, Jiri Vanek wrote: > On 02/07/2018 06:38 AM, Weijun Wang wrote: >> >> >>> On Feb 7, 2018, at 9:51 AM, Felix Yang wrote: >>> >>> Hi Max, >>> >>> ???? I have another idea, how about make the test libs into JPMS >>> modules. Then the dependencies will be explicitly described at where >>> it happens. Any comment? >> >> Your proposed change seems too big to me, and I'm not sure how to do >> it, and the size of a module, etc. >> > > This would be hardly compatible with older jdk, wouldnt it? For OpenJDK, the tests are associated with the JDK repo, and so we could use modules for library code that is specific to a version of JDK.?? I agree that for modules could not be used for any libraries for additional tests that need to run on older versions of JDK. -- Jon > >> --Max >> >>> >>> -Felix >>> On 2018/2/6 21:51, Weijun Wang wrote: >>>> While I am not requesting for an automatic discovery of @module >>>> tags, I wonder if we can enhance jtreg from another angle to make >>>> test writing a little easier. >>>> >>>> The "@modules java.security.jgss/sun.security.krb5.*" example is >>>> painful because these --add-exports are not required by the tests >>>> themselves. Instead, it's a library class (KDC.java in the same >>>> directory) they are using that is accessing these internal classes. >>>> This explains why the @module tags appear in multiple tests but you >>>> won't see any of these tests importing a class in those packages. >>>> >>>> Think of this extreme example, suppose someone adds a reference to >>>> an internal class in ProcessTools.java, then suddenly all tests >>>> using it require a new @module tag. >>>> >>>> So, is it possible to add the @module tags to that library class? >>>> >>>> /* >>>> ? * @library >>>> ? * @module .... >>>> ? */ >>>> >>>> Thanks >>>> Max >>>> >>> >> > > From alexandre.iline at oracle.com Wed Feb 7 16:57:16 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 7 Feb 2018 08:57:16 -0800 Subject: RFC: add starred module(s) In-Reply-To: References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> Message-ID: <710F0EF4-EB99-4A3B-922D-6D921DAABC1B@oracle.com> +1 We have (at least Jon and myself) in the past discussed an idea to have a separate tool to verify @module tags in tests. I too was originally suggesting to change JTReg for that and Jon convinced me that is not the best way to go. Last time we discussed that perhaps such tool could be a part of JTReg source repository, and even a part of JTReg distribution (?) but not the JTReg itself. I think it is important to agree on what this tool would be doing exactly, before proceeding to an implementation. I have some internal code which is doing some of the things - I would be glad to contribute that if it helps others. Shura > On Feb 7, 2018, at 8:14 AM, Jonathan Gibbons wrote: > > Jiri, > > I would not expect to see functionality like this available while tests are running. It might be reasonable to provide it as a separate utility, such that a test author can run it, and decide whether to incorporate or augment the output from such a utility in the test code, in the same way that import statements are not inferred by javac, but can be generated by an IDE. > > -- Jon > > > On 2/6/18 2:54 AM, Jiri Vanek wrote: >> Hi guys! >> >> Thank you for all you detailed answers. Really appreciated. >> We created generator of @module tag from javac+java output to workaround it. >> >> Is there possible desire to include something like it into jtreg itself? >> >> Thanx again! >> J. >> On 12/20/2017 06:27 PM, Jonathan Gibbons wrote: >>> >>> >>> On 12/20/17 9:14 AM, Jiri Vanek wrote: >>>> On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: >>>>> Hi. >>>>> >>>>> I just wanted to commend on enhancing JTreg to automatically calculate module dependencies. Yes, compiler knows the direct static dependencies of the compiler code, but that is not all that is needed to be known. @module annotation is used for a few not completely related things. Besides requesting "--add-exports?, it can also request "--add-opens" and it can influence test selection during execution. Of this three usages, only one could be covered by static dependency analysis. >>>>> >>>> >>>> >>>> Thank you very much for this input! >>>> >>>> From what you are saying, the need for more support of @module-whatever is needed - and doable. >>>> Current @modules is adding --add-exports and --add-opens of the modules you specified to the command. >>>> If there will be way to add exports and opens of those, which can be covered by static analyse, then it will be already more then helpfull! Especially if you will be able to add some more manually. >>>> Of course more granular support like @modules-export and @modules-opens and similar would be nice, but Thats more far away from this proposal. >>>> >>>> J. >>> >>> Jiri, >>> >>> To be clear ... it is not reasonable to add such support for an enhanced @modules for use at the time the test is selected for execution and then subsequently executed. If nothing else, there is a big chicken-and-egg problem here ... you cannot analyse the test code until it has been compiled, and you cannot compile it until you know the module dependencies. >>> >>> In general, for existing JDK tests, the @modules have been determined. For new tests, I recommend you look to your IDE or other development-time tools, to help determine the dependencies of the test code, and then record the results in an @modules tag in the test description. >>> >>> -- Jon >>> >>>> >>>>> >>>>>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >>>>>> >>>>>> Hi Jonathan! >>>>>> >>>>>> Thank you very much for great answer. Few remarks inline. >>>>>> >>>>>> >>>>>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>>>>>> Jiri, Mila, >>>>>>> There are three significant questions here. >>>>>>> 1. @modules all-needed >>>>>>> This is a non-starter. @modules participates in a relatively light-weight test selection mechanism >>>>>> >>>>>> Sure. It is last step, if it will be ever started. >>>>>> >>>>>>> ... i.e. tests are not selected if the specified modules are not available in the system image. Having jtreg analyse the source code to determine the set of necessary modules is just not practical. >>>>>>> 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* >>>>>>> Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It requires that we can list the (internal) packages of a module. Yes, there may be a attribute that provides the info, but the attribute is not guaranteed to be available, and if it's not, you're >>>>>> terrible truth. see at bottom. >>>>>> >>>>>>> reduced to scanning the module contents. On the desirability point of view, the use of this sort of syntax was discussed, and rejected, for module declarations, and while that is separate from what is >>>>>> >>>>>> I was reading most of this discussion, and I can agree with it for final deployment, but not for testing. >>>>>>> proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for the Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for those options. >>>>>> >>>>>> This is probably the only sentence I moreover disagree with you. Jtreg is far away fro being tinny wrapper, and it always did huge help for tests authors. So helping testers with setting up module path a bit, may be good step. >>>>>>> One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just having a single @modules directive with many arg values, possibly spanning many lines, as in ... >>>>>>> * .... >>>>>>> * @modules java.security.jgss/sun.security.krb5.internal >>>>>>> * java.security.jgss/sun.security.krb5.internal.ccache >>>>>>> * java.security.jgss/sun.security.krb5.internal.crypto >>>>>>> * java.security.jgss/sun.security.krb5.internal.ktab >>>>>>> * java.base/sun.security.util >>>>>>> * java.security.jgss/sun.security.jgss >>>>>> >>>>>> Still you need to enumerate them all. That mean to run javac and jmod in loops one by one, untill you get collect them. >>>>>>> 3. Shell scripts. >>>>>>> Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we have made efforts to convert many/most JDK shell tests to Java code. The general experience was that such tests were very fragile, and were often wrong/broken. They typically execute slower than equivalent Java code, especially when using libraries providing commonly-used or domain-specific functionality. >>>>>> >>>>>> Well, shell lunchers have theirs dark sides, thats right. But are awesome feature without replacement. >>>>>>> And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if present for JDK 8 tests). >>>>>> >>>>>> Its a bug :) >>>>>>> When using Java code instead of shell scripts, you can look to libraries in the various test suites for suggestions on useful methods to provide, such as invoking generating and compiling source code, providing simple equivalents for regex search (simple grep), comparison (simple diff), etc, as well as support for running subprocesses when necessary. One common pattern is to use Java code to validate whether it is appropriate to run a test in the current configuration and to then launch a JVM with a selected combination of options. This sort of mode has explicit support in jtreg: "@run driver" is similar to "@run main" for running a class, but it is not run with any JVM options intended for test JVMs. This makes it suitable for running "test driver" classes which spawn JVMs to run the "real" test code. And if you're just writing API tests, then I recommend using plain old Java code and "agentvm" mode to have the tests as fast as possible. >>>>>> >>>>>> >>>>>> You are mostly right. But consider this: The locating of modules is painful when you are dealing with private apis. And that is what you do in jtregs for half of the time... >>>>>> So naturally, the help would be easy. >>>>>> On contrary, the help do not come from JDK itself in any "supported" way (or am I missing something?) >>>>>> Still the javac can do so. So it would be natural to enahnce javac to help with this a bit more via some more solid api. Maybe you know something here? >>>>>> >>>>>> One would say, that writing private api jtreg is one or two modules usage only. Unluckily, oposite is true, and Mila's * idea is another proof of it. And If I look to past to my recent work, I was facing the same. Just got angry later. >>>>>> >>>>>> >>>>>> So generally - some help should be provided in JDK to deal with it. And as JDK looks to have its reasons to not to do so, Jtregs should. >>>>>> >>>>>> >>>>>> Thanx for again for your reply! >>>>>> J. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From jonathan.gibbons at oracle.com Wed Feb 7 17:57:11 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 Feb 2018 09:57:11 -0800 Subject: RFC: add starred module(s) In-Reply-To: <710F0EF4-EB99-4A3B-922D-6D921DAABC1B@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <710F0EF4-EB99-4A3B-922D-6D921DAABC1B@oracle.com> Message-ID: <5A7B3DF7.7000209@oracle.com> I think it would be a challenge to fit such a utility into the jtreg command line, and so at least to begin with, a separate utility would be a better sandbox for experimentation. -- Jon On 02/07/2018 08:57 AM, Alexandre (Shura) Iline wrote: > +1 > > We have (at least Jon and myself) in the past discussed an idea to have a separate tool to verify @module tags in tests. I too was originally suggesting to change JTReg for that and Jon convinced me that is not the best way to go. Last time we discussed that perhaps such tool could be a part of JTReg source repository, and even a part of JTReg distribution (?) but not the JTReg itself. > > I think it is important to agree on what this tool would be doing exactly, before proceeding to an implementation. I have some internal code which is doing some of the things - I would be glad to contribute that if it helps others. > > Shura > >> On Feb 7, 2018, at 8:14 AM, Jonathan Gibbons wrote: >> >> Jiri, >> >> I would not expect to see functionality like this available while tests are running. It might be reasonable to provide it as a separate utility, such that a test author can run it, and decide whether to incorporate or augment the output from such a utility in the test code, in the same way that import statements are not inferred by javac, but can be generated by an IDE. >> >> -- Jon >> >> >> On 2/6/18 2:54 AM, Jiri Vanek wrote: >>> Hi guys! >>> >>> Thank you for all you detailed answers. Really appreciated. >>> We created generator of @module tag from javac+java output to workaround it. >>> >>> Is there possible desire to include something like it into jtreg itself? >>> >>> Thanx again! >>> J. >>> On 12/20/2017 06:27 PM, Jonathan Gibbons wrote: >>>> >>>> On 12/20/17 9:14 AM, Jiri Vanek wrote: >>>>> On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: >>>>>> Hi. >>>>>> >>>>>> I just wanted to commend on enhancing JTreg to automatically calculate module dependencies. Yes, compiler knows the direct static dependencies of the compiler code, but that is not all that is needed to be known. @module annotation is used for a few not completely related things. Besides requesting "--add-exports?, it can also request "--add-opens" and it can influence test selection during execution. Of this three usages, only one could be covered by static dependency analysis. >>>>>> >>>>> >>>>> Thank you very much for this input! >>>>> >>>>> From what you are saying, the need for more support of @module-whatever is needed - and doable. >>>>> Current @modules is adding --add-exports and --add-opens of the modules you specified to the command. >>>>> If there will be way to add exports and opens of those, which can be covered by static analyse, then it will be already more then helpfull! Especially if you will be able to add some more manually. >>>>> Of course more granular support like @modules-export and @modules-opens and similar would be nice, but Thats more far away from this proposal. >>>>> >>>>> J. >>>> Jiri, >>>> >>>> To be clear ... it is not reasonable to add such support for an enhanced @modules for use at the time the test is selected for execution and then subsequently executed. If nothing else, there is a big chicken-and-egg problem here ... you cannot analyse the test code until it has been compiled, and you cannot compile it until you know the module dependencies. >>>> >>>> In general, for existing JDK tests, the @modules have been determined. For new tests, I recommend you look to your IDE or other development-time tools, to help determine the dependencies of the test code, and then record the results in an @modules tag in the test description. >>>> >>>> -- Jon >>>> >>>>>>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >>>>>>> >>>>>>> Hi Jonathan! >>>>>>> >>>>>>> Thank you very much for great answer. Few remarks inline. >>>>>>> >>>>>>> >>>>>>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>>>>>>> Jiri, Mila, >>>>>>>> There are three significant questions here. >>>>>>>> 1. @modules all-needed >>>>>>>> This is a non-starter. @modules participates in a relatively light-weight test selection mechanism >>>>>>> Sure. It is last step, if it will be ever started. >>>>>>> >>>>>>>> ... i.e. tests are not selected if the specified modules are not available in the system image. Having jtreg analyse the source code to determine the set of necessary modules is just not practical. >>>>>>>> 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* >>>>>>>> Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It requires that we can list the (internal) packages of a module. Yes, there may be a attribute that provides the info, but the attribute is not guaranteed to be available, and if it's not, you're >>>>>>> terrible truth. see at bottom. >>>>>>> >>>>>>>> reduced to scanning the module contents. On the desirability point of view, the use of this sort of syntax was discussed, and rejected, for module declarations, and while that is separate from what is >>>>>>> I was reading most of this discussion, and I can agree with it for final deployment, but not for testing. >>>>>>>> proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for the Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for those options. >>>>>>> This is probably the only sentence I moreover disagree with you. Jtreg is far away fro being tinny wrapper, and it always did huge help for tests authors. So helping testers with setting up module path a bit, may be good step. >>>>>>>> One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just having a single @modules directive with many arg values, possibly spanning many lines, as in ... >>>>>>>> * .... >>>>>>>> * @modules java.security.jgss/sun.security.krb5.internal >>>>>>>> * java.security.jgss/sun.security.krb5.internal.ccache >>>>>>>> * java.security.jgss/sun.security.krb5.internal.crypto >>>>>>>> * java.security.jgss/sun.security.krb5.internal.ktab >>>>>>>> * java.base/sun.security.util >>>>>>>> * java.security.jgss/sun.security.jgss >>>>>>> Still you need to enumerate them all. That mean to run javac and jmod in loops one by one, untill you get collect them. >>>>>>>> 3. Shell scripts. >>>>>>>> Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we have made efforts to convert many/most JDK shell tests to Java code. The general experience was that such tests were very fragile, and were often wrong/broken. They typically execute slower than equivalent Java code, especially when using libraries providing commonly-used or domain-specific functionality. >>>>>>> Well, shell lunchers have theirs dark sides, thats right. But are awesome feature without replacement. >>>>>>>> And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if present for JDK 8 tests). >>>>>>> Its a bug :) >>>>>>>> When using Java code instead of shell scripts, you can look to libraries in the various test suites for suggestions on useful methods to provide, such as invoking generating and compiling source code, providing simple equivalents for regex search (simple grep), comparison (simple diff), etc, as well as support for running subprocesses when necessary. One common pattern is to use Java code to validate whether it is appropriate to run a test in the current configuration and to then launch a JVM with a selected combination of options. This sort of mode has explicit support in jtreg: "@run driver" is similar to "@run main" for running a class, but it is not run with any JVM options intended for test JVMs. This makes it suitable for running "test driver" classes which spawn JVMs to run the "real" test code. And if you're just writing API tests, then I recommend using plain old Java code and "agentvm" mode to have the tests as fast as possible. >>>>>>> >>>>>>> You are mostly right. But consider this: The locating of modules is painful when you are dealing with private apis. And that is what you do in jtregs for half of the time... >>>>>>> So naturally, the help would be easy. >>>>>>> On contrary, the help do not come from JDK itself in any "supported" way (or am I missing something?) >>>>>>> Still the javac can do so. So it would be natural to enahnce javac to help with this a bit more via some more solid api. Maybe you know something here? >>>>>>> >>>>>>> One would say, that writing private api jtreg is one or two modules usage only. Unluckily, oposite is true, and Mila's * idea is another proof of it. And If I look to past to my recent work, I was facing the same. Just got angry later. >>>>>>> >>>>>>> >>>>>>> So generally - some help should be provided in JDK to deal with it. And as JDK looks to have its reasons to not to do so, Jtregs should. >>>>>>> >>>>>>> >>>>>>> Thanx for again for your reply! >>>>>>> J. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> From alexandre.iline at oracle.com Wed Feb 7 21:01:41 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 7 Feb 2018 13:01:41 -0800 Subject: RFC: add starred module(s) In-Reply-To: <5A7B3DF7.7000209@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <710F0EF4-EB99-4A3B-922D-6D921DAABC1B@oracle.com> <5A7B3DF7.7000209@oracle.com> Message-ID: <2DBC097D-B32A-4D12-878F-C826B9D38D6E@oracle.com> > On Feb 7, 2018, at 9:57 AM, Jonathan Gibbons wrote: > > I think it would be a challenge to fit such a utility into the jtreg command line, This is what I meant saying that the tool would not be a part of JTReg itself. Sorry if I was not clear. Shura > and so at least to begin with, a separate utility would be a better sandbox for experimentation. > > -- Jon > > On 02/07/2018 08:57 AM, Alexandre (Shura) Iline wrote: >> +1 >> >> We have (at least Jon and myself) in the past discussed an idea to have a separate tool to verify @module tags in tests. I too was originally suggesting to change JTReg for that and Jon convinced me that is not the best way to go. Last time we discussed that perhaps such tool could be a part of JTReg source repository, and even a part of JTReg distribution (?) but not the JTReg itself. >> >> I think it is important to agree on what this tool would be doing exactly, before proceeding to an implementation. I have some internal code which is doing some of the things - I would be glad to contribute that if it helps others. >> >> Shura >> >>> On Feb 7, 2018, at 8:14 AM, Jonathan Gibbons wrote: >>> >>> Jiri, >>> >>> I would not expect to see functionality like this available while tests are running. It might be reasonable to provide it as a separate utility, such that a test author can run it, and decide whether to incorporate or augment the output from such a utility in the test code, in the same way that import statements are not inferred by javac, but can be generated by an IDE. >>> >>> -- Jon >>> >>> >>> On 2/6/18 2:54 AM, Jiri Vanek wrote: >>>> Hi guys! >>>> >>>> Thank you for all you detailed answers. Really appreciated. >>>> We created generator of @module tag from javac+java output to workaround it. >>>> >>>> Is there possible desire to include something like it into jtreg itself? >>>> >>>> Thanx again! >>>> J. >>>> On 12/20/2017 06:27 PM, Jonathan Gibbons wrote: >>>>> >>>>> On 12/20/17 9:14 AM, Jiri Vanek wrote: >>>>>> On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: >>>>>>> Hi. >>>>>>> >>>>>>> I just wanted to commend on enhancing JTreg to automatically calculate module dependencies. Yes, compiler knows the direct static dependencies of the compiler code, but that is not all that is needed to be known. @module annotation is used for a few not completely related things. Besides requesting "--add-exports?, it can also request "--add-opens" and it can influence test selection during execution. Of this three usages, only one could be covered by static dependency analysis. >>>>>>> >>>>>> >>>>>> Thank you very much for this input! >>>>>> >>>>>> From what you are saying, the need for more support of @module-whatever is needed - and doable. >>>>>> Current @modules is adding --add-exports and --add-opens of the modules you specified to the command. >>>>>> If there will be way to add exports and opens of those, which can be covered by static analyse, then it will be already more then helpfull! Especially if you will be able to add some more manually. >>>>>> Of course more granular support like @modules-export and @modules-opens and similar would be nice, but Thats more far away from this proposal. >>>>>> >>>>>> J. >>>>> Jiri, >>>>> >>>>> To be clear ... it is not reasonable to add such support for an enhanced @modules for use at the time the test is selected for execution and then subsequently executed. If nothing else, there is a big chicken-and-egg problem here ... you cannot analyse the test code until it has been compiled, and you cannot compile it until you know the module dependencies. >>>>> >>>>> In general, for existing JDK tests, the @modules have been determined. For new tests, I recommend you look to your IDE or other development-time tools, to help determine the dependencies of the test code, and then record the results in an @modules tag in the test description. >>>>> >>>>> -- Jon >>>>> >>>>>>>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >>>>>>>> >>>>>>>> Hi Jonathan! >>>>>>>> >>>>>>>> Thank you very much for great answer. Few remarks inline. >>>>>>>> >>>>>>>> >>>>>>>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>>>>>>>> Jiri, Mila, >>>>>>>>> There are three significant questions here. >>>>>>>>> 1. @modules all-needed >>>>>>>>> This is a non-starter. @modules participates in a relatively light-weight test selection mechanism >>>>>>>> Sure. It is last step, if it will be ever started. >>>>>>>> >>>>>>>>> ... i.e. tests are not selected if the specified modules are not available in the system image. Having jtreg analyse the source code to determine the set of necessary modules is just not practical. >>>>>>>>> 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* >>>>>>>>> Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It requires that we can list the (internal) packages of a module. Yes, there may be a attribute that provides the info, but the attribute is not guaranteed to be available, and if it's not, you're >>>>>>>> terrible truth. see at bottom. >>>>>>>> >>>>>>>>> reduced to scanning the module contents. On the desirability point of view, the use of this sort of syntax was discussed, and rejected, for module declarations, and while that is separate from what is >>>>>>>> I was reading most of this discussion, and I can agree with it for final deployment, but not for testing. >>>>>>>>> proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for the Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for those options. >>>>>>>> This is probably the only sentence I moreover disagree with you. Jtreg is far away fro being tinny wrapper, and it always did huge help for tests authors. So helping testers with setting up module path a bit, may be good step. >>>>>>>>> One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just having a single @modules directive with many arg values, possibly spanning many lines, as in ... >>>>>>>>> * .... >>>>>>>>> * @modules java.security.jgss/sun.security.krb5.internal >>>>>>>>> * java.security.jgss/sun.security.krb5.internal.ccache >>>>>>>>> * java.security.jgss/sun.security.krb5.internal.crypto >>>>>>>>> * java.security.jgss/sun.security.krb5.internal.ktab >>>>>>>>> * java.base/sun.security.util >>>>>>>>> * java.security.jgss/sun.security.jgss >>>>>>>> Still you need to enumerate them all. That mean to run javac and jmod in loops one by one, untill you get collect them. >>>>>>>>> 3. Shell scripts. >>>>>>>>> Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we have made efforts to convert many/most JDK shell tests to Java code. The general experience was that such tests were very fragile, and were often wrong/broken. They typically execute slower than equivalent Java code, especially when using libraries providing commonly-used or domain-specific functionality. >>>>>>>> Well, shell lunchers have theirs dark sides, thats right. But are awesome feature without replacement. >>>>>>>>> And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if present for JDK 8 tests). >>>>>>>> Its a bug :) >>>>>>>>> When using Java code instead of shell scripts, you can look to libraries in the various test suites for suggestions on useful methods to provide, such as invoking generating and compiling source code, providing simple equivalents for regex search (simple grep), comparison (simple diff), etc, as well as support for running subprocesses when necessary. One common pattern is to use Java code to validate whether it is appropriate to run a test in the current configuration and to then launch a JVM with a selected combination of options. This sort of mode has explicit support in jtreg: "@run driver" is similar to "@run main" for running a class, but it is not run with any JVM options intended for test JVMs. This makes it suitable for running "test driver" classes which spawn JVMs to run the "real" test code. And if you're just writing API tests, then I recommend using plain old Java code and "agentvm" mode to have the tests as fast as possible. >>>>>>>> >>>>>>>> You are mostly right. But consider this: The locating of modules is painful when you are dealing with private apis. And that is what you do in jtregs for half of the time... >>>>>>>> So naturally, the help would be easy. >>>>>>>> On contrary, the help do not come from JDK itself in any "supported" way (or am I missing something?) >>>>>>>> Still the javac can do so. So it would be natural to enahnce javac to help with this a bit more via some more solid api. Maybe you know something here? >>>>>>>> >>>>>>>> One would say, that writing private api jtreg is one or two modules usage only. Unluckily, oposite is true, and Mila's * idea is another proof of it. And If I look to past to my recent work, I was facing the same. Just got angry later. >>>>>>>> >>>>>>>> >>>>>>>> So generally - some help should be provided in JDK to deal with it. And as JDK looks to have its reasons to not to do so, Jtregs should. >>>>>>>> >>>>>>>> >>>>>>>> Thanx for again for your reply! >>>>>>>> J. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> > > From jonathan.gibbons at oracle.com Wed Feb 7 21:17:33 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 Feb 2018 13:17:33 -0800 Subject: RFC: add starred module(s) In-Reply-To: <2DBC097D-B32A-4D12-878F-C826B9D38D6E@oracle.com> References: <5A2B418E.9000607@oracle.com> <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> <710F0EF4-EB99-4A3B-922D-6D921DAABC1B@oracle.com> <5A7B3DF7.7000209@oracle.com> <2DBC097D-B32A-4D12-878F-C826B9D38D6E@oracle.com> Message-ID: <5A7B6CED.6010608@oracle.com> Understood. I was just explaining that rationale for suggesting a separate utility. -- Jon On 02/07/2018 01:01 PM, Alexandre (Shura) Iline wrote: > >> On Feb 7, 2018, at 9:57 AM, Jonathan Gibbons wrote: >> >> I think it would be a challenge to fit such a utility into the jtreg command line, > This is what I meant saying that the tool would not be a part of JTReg itself. Sorry if I was not clear. > > Shura > >> and so at least to begin with, a separate utility would be a better sandbox for experimentation. >> >> -- Jon >> >> On 02/07/2018 08:57 AM, Alexandre (Shura) Iline wrote: >>> +1 >>> >>> We have (at least Jon and myself) in the past discussed an idea to have a separate tool to verify @module tags in tests. I too was originally suggesting to change JTReg for that and Jon convinced me that is not the best way to go. Last time we discussed that perhaps such tool could be a part of JTReg source repository, and even a part of JTReg distribution (?) but not the JTReg itself. >>> >>> I think it is important to agree on what this tool would be doing exactly, before proceeding to an implementation. I have some internal code which is doing some of the things - I would be glad to contribute that if it helps others. >>> >>> Shura >>> >>>> On Feb 7, 2018, at 8:14 AM, Jonathan Gibbons wrote: >>>> >>>> Jiri, >>>> >>>> I would not expect to see functionality like this available while tests are running. It might be reasonable to provide it as a separate utility, such that a test author can run it, and decide whether to incorporate or augment the output from such a utility in the test code, in the same way that import statements are not inferred by javac, but can be generated by an IDE. >>>> >>>> -- Jon >>>> >>>> >>>> On 2/6/18 2:54 AM, Jiri Vanek wrote: >>>>> Hi guys! >>>>> >>>>> Thank you for all you detailed answers. Really appreciated. >>>>> We created generator of @module tag from javac+java output to workaround it. >>>>> >>>>> Is there possible desire to include something like it into jtreg itself? >>>>> >>>>> Thanx again! >>>>> J. >>>>> On 12/20/2017 06:27 PM, Jonathan Gibbons wrote: >>>>>> On 12/20/17 9:14 AM, Jiri Vanek wrote: >>>>>>> On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: >>>>>>>> Hi. >>>>>>>> >>>>>>>> I just wanted to commend on enhancing JTreg to automatically calculate module dependencies. Yes, compiler knows the direct static dependencies of the compiler code, but that is not all that is needed to be known. @module annotation is used for a few not completely related things. Besides requesting "--add-exports?, it can also request "--add-opens" and it can influence test selection during execution. Of this three usages, only one could be covered by static dependency analysis. >>>>>>>> >>>>>>> Thank you very much for this input! >>>>>>> >>>>>>> From what you are saying, the need for more support of @module-whatever is needed - and doable. >>>>>>> Current @modules is adding --add-exports and --add-opens of the modules you specified to the command. >>>>>>> If there will be way to add exports and opens of those, which can be covered by static analyse, then it will be already more then helpfull! Especially if you will be able to add some more manually. >>>>>>> Of course more granular support like @modules-export and @modules-opens and similar would be nice, but Thats more far away from this proposal. >>>>>>> >>>>>>> J. >>>>>> Jiri, >>>>>> >>>>>> To be clear ... it is not reasonable to add such support for an enhanced @modules for use at the time the test is selected for execution and then subsequently executed. If nothing else, there is a big chicken-and-egg problem here ... you cannot analyse the test code until it has been compiled, and you cannot compile it until you know the module dependencies. >>>>>> >>>>>> In general, for existing JDK tests, the @modules have been determined. For new tests, I recommend you look to your IDE or other development-time tools, to help determine the dependencies of the test code, and then record the results in an @modules tag in the test description. >>>>>> >>>>>> -- Jon >>>>>> >>>>>>>>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >>>>>>>>> >>>>>>>>> Hi Jonathan! >>>>>>>>> >>>>>>>>> Thank you very much for great answer. Few remarks inline. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>>>>>>>>> Jiri, Mila, >>>>>>>>>> There are three significant questions here. >>>>>>>>>> 1. @modules all-needed >>>>>>>>>> This is a non-starter. @modules participates in a relatively light-weight test selection mechanism >>>>>>>>> Sure. It is last step, if it will be ever started. >>>>>>>>> >>>>>>>>>> ... i.e. tests are not selected if the specified modules are not available in the system image. Having jtreg analyse the source code to determine the set of necessary modules is just not practical. >>>>>>>>>> 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* >>>>>>>>>> Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It requires that we can list the (internal) packages of a module. Yes, there may be a attribute that provides the info, but the attribute is not guaranteed to be available, and if it's not, you're >>>>>>>>> terrible truth. see at bottom. >>>>>>>>> >>>>>>>>>> reduced to scanning the module contents. On the desirability point of view, the use of this sort of syntax was discussed, and rejected, for module declarations, and while that is separate from what is >>>>>>>>> I was reading most of this discussion, and I can agree with it for final deployment, but not for testing. >>>>>>>>>> proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for the Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for those options. >>>>>>>>> This is probably the only sentence I moreover disagree with you. Jtreg is far away fro being tinny wrapper, and it always did huge help for tests authors. So helping testers with setting up module path a bit, may be good step. >>>>>>>>>> One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just having a single @modules directive with many arg values, possibly spanning many lines, as in ... >>>>>>>>>> * .... >>>>>>>>>> * @modules java.security.jgss/sun.security.krb5.internal >>>>>>>>>> * java.security.jgss/sun.security.krb5.internal.ccache >>>>>>>>>> * java.security.jgss/sun.security.krb5.internal.crypto >>>>>>>>>> * java.security.jgss/sun.security.krb5.internal.ktab >>>>>>>>>> * java.base/sun.security.util >>>>>>>>>> * java.security.jgss/sun.security.jgss >>>>>>>>> Still you need to enumerate them all. That mean to run javac and jmod in loops one by one, untill you get collect them. >>>>>>>>>> 3. Shell scripts. >>>>>>>>>> Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we have made efforts to convert many/most JDK shell tests to Java code. The general experience was that such tests were very fragile, and were often wrong/broken. They typically execute slower than equivalent Java code, especially when using libraries providing commonly-used or domain-specific functionality. >>>>>>>>> Well, shell lunchers have theirs dark sides, thats right. But are awesome feature without replacement. >>>>>>>>>> And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if present for JDK 8 tests). >>>>>>>>> Its a bug :) >>>>>>>>>> When using Java code instead of shell scripts, you can look to libraries in the various test suites for suggestions on useful methods to provide, such as invoking generating and compiling source code, providing simple equivalents for regex search (simple grep), comparison (simple diff), etc, as well as support for running subprocesses when necessary. One common pattern is to use Java code to validate whether it is appropriate to run a test in the current configuration and to then launch a JVM with a selected combination of options. This sort of mode has explicit support in jtreg: "@run driver" is similar to "@run main" for running a class, but it is not run with any JVM options intended for test JVMs. This makes it suitable for running "test driver" classes which spawn JVMs to run the "real" test code. And if you're just writing API tests, then I recommend using plain old Java code and "agentvm" mode to have the tests as fast as possible. >>>>>>>>> You are mostly right. But consider this: The locating of modules is painful when you are dealing with private apis. And that is what you do in jtregs for half of the time... >>>>>>>>> So naturally, the help would be easy. >>>>>>>>> On contrary, the help do not come from JDK itself in any "supported" way (or am I missing something?) >>>>>>>>> Still the javac can do so. So it would be natural to enahnce javac to help with this a bit more via some more solid api. Maybe you know something here? >>>>>>>>> >>>>>>>>> One would say, that writing private api jtreg is one or two modules usage only. Unluckily, oposite is true, and Mila's * idea is another proof of it. And If I look to past to my recent work, I was facing the same. Just got angry later. >>>>>>>>> >>>>>>>>> >>>>>>>>> So generally - some help should be provided in JDK to deal with it. And as JDK looks to have its reasons to not to do so, Jtregs should. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanx for again for your reply! >>>>>>>>> J. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> From zzambers at redhat.com Thu Feb 8 12:41:52 2018 From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=) Date: Thu, 8 Feb 2018 13:41:52 +0100 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: <749386dd-45a9-0683-3ef8-34d44055c341@oracle.com> References: <991930f2-0f30-f8c5-179a-8f9b12c8b4e0@redhat.com> <693d59ee-bc3e-1aae-fc26-2f591c2641cf@redhat.com> <749386dd-45a9-0683-3ef8-34d44055c341@oracle.com> Message-ID: On 02/06/2018 05:36 PM, Jonathan Gibbons wrote: > Jiri, Mila, > > I wonder why the fix is necessary. > > TESTMODULES contains a property of the test description (the @modules > entry).? The env variable will not be set if the value is empty. > > So, given that (versions of) test suites are generally specific to a > version of the JDK, I wonder why you are trying to run tests with > @module entries on a non-modular JDK. > > And, if there is a plausible test case for such tests, the fix is > arguably incomplete, because the TEST* environment variables for shell > tests mirror the test.* system properties for Java tests. > > I think a better direction would be to warn against the use of > @modules on a non-modular JDK. > > -- Jon ... this reply surprised me a bit Actually we have big jtreg test suites, which we run on various JDKs (both modular and non-modular). Most of these are java jtregs, where we fixed lot of them to work on both modular and non-modular JDKs, by adding @modules tag. But some of these tests use shell scripts (various special cases), so being able to infer modularity of JDK from environment variables in these (shell jtreg tests), would be very convenient. We definitely do not favor duplication of tests for modular JDK... > > On 2/6/18 2:55 AM, Jiri Vanek wrote: >> On 12/20/2017 05:35 PM, Jiri Vanek wrote: >>> On 12/15/2017 11:37 AM, Miloslav Zezulka wrote: >>>> This is a very small patch fixing the issue pointed out in >>>> $subject. I've >>>> added checks for both compile and test JDK - is this an overkill, >>>> since >>>> most of the time the implication goes COMPILEJDK.modular => >>>> TESTJDK.modular, or a necessary thing to have for foolproofness? >>> >> ping? >>> >>> Works fine. Johnatan, can you push it? Or do you wont mila to create >>> regular webrev? Is there some place to add test for it? >>> >>> Tahnx a lot! >>> ?? J. >>> >>> >> >> > best regards, -- Zden?k ?ambersk? OpenJDK QE Red Hat From jonathan.gibbons at oracle.com Thu Feb 8 15:58:29 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 8 Feb 2018 07:58:29 -0800 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: References: <991930f2-0f30-f8c5-179a-8f9b12c8b4e0@redhat.com> <693d59ee-bc3e-1aae-fc26-2f591c2641cf@redhat.com> <749386dd-45a9-0683-3ef8-34d44055c341@oracle.com> Message-ID: <2a24c095-058d-b49c-a614-290a7eb88bbb@oracle.com> On 2/8/18 4:41 AM, Zden?k ?ambersk? wrote: > On 02/06/2018 05:36 PM, Jonathan Gibbons wrote: >> Jiri, Mila, >> >> I wonder why the fix is necessary. >> >> TESTMODULES contains a property of the test description (the @modules >> entry).? The env variable will not be set if the value is empty. >> >> So, given that (versions of) test suites are generally specific to a >> version of the JDK, I wonder why you are trying to run tests with >> @module entries on a non-modular JDK. >> >> And, if there is a plausible test case for such tests, the fix is >> arguably incomplete, because the TEST* environment variables for >> shell tests mirror the test.* system properties for Java tests. >> >> I think a better direction would be to warn against the use of >> @modules on a non-modular JDK. >> >> -- Jon > > ... this reply surprised me a bit > > Actually we have big jtreg test suites, which we run on various JDKs > (both modular and non-modular). Most of these are java jtregs, > where we fixed lot of them to work on both modular and non-modular JDKs, > by adding @modules tag. But some of these tests use shell scripts > (various special cases), so being able to infer modularity of JDK from > environment variables in these (shell jtreg tests), would be very > convenient. > > We definitely do not favor duplication of tests for modular JDK... Inferring the modularity of the JDK should be done by examining the (version of the) JDK, not by relying on a value derived from an optional setting in a test description. -- Jon > >> >> On 2/6/18 2:55 AM, Jiri Vanek wrote: >>> On 12/20/2017 05:35 PM, Jiri Vanek wrote: >>>> On 12/15/2017 11:37 AM, Miloslav Zezulka wrote: >>>>> This is a very small patch fixing the issue pointed out in >>>>> $subject. I've >>>>> added checks for both compile and test JDK - is this an overkill, >>>>> since >>>>> most of the time the implication goes COMPILEJDK.modular => >>>>> TESTJDK.modular, or a necessary thing to have for foolproofness? >>>> >>> ping? >>>> >>>> Works fine. Johnatan, can you push it? Or do you wont mila to >>>> create regular webrev? Is there some place to add test for it? >>>> >>>> Tahnx a lot! >>>> ?? J. >>>> >>>> >>> >>> >> > > best regards, > From jonathan.gibbons at oracle.com Fri Feb 9 21:33:27 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 09 Feb 2018 21:33:27 +0000 Subject: hg: code-tools/jtreg: Fix typo in Defs.gmk, and update modlibs test Message-ID: <201802092133.w19LXRK5028985@aojmv0008.oracle.com> Changeset: 35c68ceff115 Author: jjg Date: 2018-02-09 13:28 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/35c68ceff115 Fix typo in Defs.gmk, and update modlibs test ! make/Defs.gmk ! test/modlibs/TEST.ROOT From jonathan.gibbons at oracle.com Fri Feb 9 22:37:15 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 09 Feb 2018 22:37:15 +0000 Subject: hg: code-tools/jtreg: 2 new changesets Message-ID: <201802092237.w19MbFwn023313@aojmv0008.oracle.com> Changeset: 76f56eddfbde Author: jjg Date: 2018-02-09 13:40 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/76f56eddfbde Warn if compileJDK version does not match testJDK version ! src/share/classes/com/sun/javatest/regtest/tool/Tool.java + test/versionCheck/TEST.ROOT + test/versionCheck/Test.java + test/versionCheck/TestVersionCheck.gmk Changeset: ef79c206c726 Author: jjg Date: 2018-02-09 14:32 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/ef79c206c726 Ignore @modules when test JDK does not support modules ! src/share/classes/com/sun/javatest/regtest/config/Modules.java ! src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java ! src/share/doc/javatest/regtest/tag-spec.html ! test/modules/ModulesTest.gmk + test/modules/ModulesTest.sh From jonathan.gibbons at oracle.com Sat Feb 10 00:31:18 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 09 Feb 2018 16:31:18 -0800 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: References: Message-ID: <5A7E3D56.3000602@oracle.com> Mila, I have pushed a variant of your fix, along with spec updates and tests. In a related fix, jtreg will now report a warning if the version of the compile JDK does not match the version of the test JDK. -- Jon On 12/15/2017 02:37 AM, Miloslav Zezulka wrote: > This is a very small patch fixing the issue pointed out in $subject. I've > added checks for both compile and test JDK - is this an overkill, since > most of the time the implication goes COMPILEJDK.modular => > TESTJDK.modular, or a necessary thing to have for foolproofness? > > Please let me know what you think. > > Thanks, > Mila From mzezulka at redhat.com Mon Feb 12 12:16:46 2018 From: mzezulka at redhat.com (Miloslav Zezulka) Date: Mon, 12 Feb 2018 13:16:46 +0100 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: <5A7E3D56.3000602@oracle.com> References: <5A7E3D56.3000602@oracle.com> Message-ID: > I have pushed a variant of your fix, along with spec updates and tests. > In a related fix, jtreg will now report a warning if the version of the compile JDK > does not match the version of the test JDK. Thanks! On Sat, Feb 10, 2018 at 1:31 AM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Mila, > > I have pushed a variant of your fix, along with spec updates and tests. > In a related fix, jtreg will now report a warning if the version of the > compile JDK > does not match the version of the test JDK. > > -- Jon > > > > On 12/15/2017 02:37 AM, Miloslav Zezulka wrote: > >> This is a very small patch fixing the issue pointed out in $subject. I've >> added checks for both compile and test JDK - is this an overkill, since >> most of the time the implication goes COMPILEJDK.modular => >> TESTJDK.modular, or a necessary thing to have for foolproofness? >> >> Please let me know what you think. >> >> Thanks, >> Mila >> > > From zzambers at redhat.com Mon Feb 12 15:14:16 2018 From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=) Date: Mon, 12 Feb 2018 16:14:16 +0100 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: References: <5A7E3D56.3000602@oracle.com> Message-ID: <608154ee-da37-fe6b-3d26-f34daa74881b@redhat.com> On 02/12/2018 01:16 PM, Miloslav Zezulka wrote: >> I have pushed a variant of your fix, along with spec updates and tests. >> In a related fix, jtreg will now report a warning if the version of the > compile JDK >> does not match the version of the test JDK. > Thanks! I already tried to do Jtreg build with latest changes and I can confirm, that TESTMODULES env. var. is now only exportedin shell tests, when testing modular JDK. When it comes to java jtreg tests it works as previously, @modules tag makes them work on modular JDK, but running them on non-modular JDK is still possible. Thank you both. > > On Sat, Feb 10, 2018 at 1:31 AM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> Mila, >> >> I have pushed a variant of your fix, along with spec updates and tests. >> In a related fix, jtreg will now report a warning if the version of the >> compile JDK >> does not match the version of the test JDK. >> >> -- Jon >> >> >> >> On 12/15/2017 02:37 AM, Miloslav Zezulka wrote: >> >>> This is a very small patch fixing the issue pointed out in $subject. I've >>> added checks for both compile and test JDK - is this an overkill, since >>> most of the time the implication goes COMPILEJDK.modular => >>> TESTJDK.modular, or a necessary thing to have for foolproofness? >>> >>> Please let me know what you think. >>> >>> Thanks, >>> Mila >>> >> -- Zden?k ?ambersk? OpenJDK QE Red Hat From zzambers at redhat.com Tue Feb 13 15:21:31 2018 From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=) Date: Tue, 13 Feb 2018 16:21:31 +0100 Subject: Modules params in shell tests on modular JDK Message-ID: <77f8dd75-634b-ec37-90a0-f42b242cf46c@redhat.com> Hi, I am currently trying to make some jtreg shell tests work on modular jdk. And while TESTMODULES env. variable gives me list of required modules, there is still need for additional code to transform it to parameters for java, javac (these --add-modules, --add-exports params ). I ended up with something like this: ADD_MODULES_PARAMS="" ADD_EXPORTS_PARAMS="" if [ -n "${TESTMODULES}" ] ; then ??? ADD_MODULES_PARAMS="--add-modules $( printf "%s" "${TESTMODULES}" \ ??? ??? | sed 's/\([^/[:space:]]\+\)\(\/[^[:space:]]*\)*[[:space:]]*/\1,/g' )" ??? ADD_MODULES_PARAMS="${ADD_MODULES_PARAMS%,}" ??? ADD_EXPORTS_PARAMS="$( printf "%s" "${TESTMODULES}" \ ??? ??? | sed 's/[^[:space:]]\+/--add-exports &=ALL-UNNAMED/g' )" fi I wonder if env. variable with generated parameters could be passed toshell tests by environment to simplify shell jtreg tests for modular JDK? best regards, -- Zden?k ?ambersk? OpenJDK QE Red Hat From mzezulka at redhat.com Tue Feb 13 15:42:15 2018 From: mzezulka at redhat.com (Miloslav Zezulka) Date: Tue, 13 Feb 2018 16:42:15 +0100 Subject: Modules params in shell tests on modular JDK In-Reply-To: <77f8dd75-634b-ec37-90a0-f42b242cf46c@redhat.com> References: <77f8dd75-634b-ec37-90a0-f42b242cf46c@redhat.com> Message-ID: > ADD_MODULES_PARAMS="" > ADD_EXPORTS_PARAMS="" > if [ -n "${TESTMODULES}" ] ; then > ADD_MODULES_PARAMS="--add-modules $( printf "%s" "${TESTMODULES}" \ > | sed 's/\([^/[:space:]]\+\)\(\/[^[:space:]]*\)*[[:space:]]*/\1,/g' )" > ADD_MODULES_PARAMS="${ADD_MODULES_PARAMS%,}" > > ADD_EXPORTS_PARAMS="$( printf "%s" "${TESTMODULES}" \ > | sed 's/[^[:space:]]\+/--add-exports &=ALL-UNNAMED/g' )" > fi It is also worth mentioning that this work is already done in com.sun.javatest.regtest.exec.Action.getExtraModuleConfigOptions method for the purposes of Java jtregs. However, this @modules -> "--add-exports ..." conversion is also available for the ShellAction subclass, so why not make it available for shell tests, too? It makes more sense to me than the awkward sed script above. On Tue, Feb 13, 2018 at 4:21 PM, Zden?k ?ambersk? wrote: > Hi, > > I am currently trying to make some jtreg shell tests work on modular jdk. > And while TESTMODULES env. variable gives me list of required modules, > there is still need for additional code to transform it to parameters > for java, javac (these --add-modules, --add-exports params ). > > I ended up with something like this: > > ADD_MODULES_PARAMS="" > ADD_EXPORTS_PARAMS="" > if [ -n "${TESTMODULES}" ] ; then > ADD_MODULES_PARAMS="--add-modules $( printf "%s" "${TESTMODULES}" \ > | sed 's/\([^/[:space:]]\+\)\(\/[^[:space:]]*\)*[[:space:]]*/\1,/g' > )" > ADD_MODULES_PARAMS="${ADD_MODULES_PARAMS%,}" > > ADD_EXPORTS_PARAMS="$( printf "%s" "${TESTMODULES}" \ > | sed 's/[^[:space:]]\+/--add-exports &=ALL-UNNAMED/g' )" > fi > > I wonder if env. variable with generated parameters > could be passed toshell tests by environment to simplify > shell jtreg tests for modular JDK? > > best regards, > > -- > Zden?k ?ambersk? > OpenJDK QE > Red Hat > > From jonathan.gibbons at oracle.com Tue Feb 13 21:34:29 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 13 Feb 2018 13:34:29 -0800 Subject: Modules params in shell tests on modular JDK In-Reply-To: <77f8dd75-634b-ec37-90a0-f42b242cf46c@redhat.com> References: <77f8dd75-634b-ec37-90a0-f42b242cf46c@redhat.com> Message-ID: <5A8359E5.3040301@oracle.com> I would again encourage you to be moving away from shell tests in favor of tests written in Java. That is the general direction for all OpenJDK tests. Tests can be faster, and it is certainly easier to write and use library code in Java to handle the sort of task you are doing here. -- Jon On 02/13/2018 07:21 AM, Zden?k ?ambersk? wrote: > Hi, > > I am currently trying to make some jtreg shell tests work on modular jdk. > And while TESTMODULES env. variable gives me list of required modules, > there is still need for additional code to transform it to parameters > for java, javac (these --add-modules, --add-exports params ). > > I ended up with something like this: > > ADD_MODULES_PARAMS="" > ADD_EXPORTS_PARAMS="" > if [ -n "${TESTMODULES}" ] ; then > ADD_MODULES_PARAMS="--add-modules $( printf "%s" "${TESTMODULES}" \ > | sed > 's/\([^/[:space:]]\+\)\(\/[^[:space:]]*\)*[[:space:]]*/\1,/g' )" > ADD_MODULES_PARAMS="${ADD_MODULES_PARAMS%,}" > > ADD_EXPORTS_PARAMS="$( printf "%s" "${TESTMODULES}" \ > | sed 's/[^[:space:]]\+/--add-exports &=ALL-UNNAMED/g' )" > fi > > I wonder if env. variable with generated parameters > could be passed toshell tests by environment to simplify > shell jtreg tests for modular JDK? > > best regards, > From jonathan.gibbons at oracle.com Tue Feb 13 23:43:38 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 13 Feb 2018 23:43:38 +0000 Subject: hg: code-tools/jtreg: add test to confirm system properties available in driver Message-ID: <201802132343.w1DNhcge019241@aojmv0008.oracle.com> Changeset: 7740b27ddd14 Author: jjg Date: 2018-02-13 15:39 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/7740b27ddd14 add test to confirm system properties available in driver ! src/share/classes/com/sun/javatest/regtest/exec/DriverAction.java + test/sysprops/SysPropsTest.gmk + test/sysprops/TEST.ROOT + test/sysprops/Test.java From jonathan.gibbons at oracle.com Tue Feb 13 23:48:34 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 13 Feb 2018 23:48:34 +0000 Subject: hg: code-tools/jtreg: minor cleanup Message-ID: <201802132348.w1DNmYEU022174@aojmv0008.oracle.com> Changeset: 1375c7a98309 Author: jjg Date: 2018-02-13 15:44 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/1375c7a98309 minor cleanup ! src/share/classes/com/sun/javatest/regtest/tool/Version.java From zzambers at redhat.com Wed Feb 14 15:11:36 2018 From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=) Date: Wed, 14 Feb 2018 16:11:36 +0100 Subject: Modules params in shell tests on modular JDK In-Reply-To: <5A8359E5.3040301@oracle.com> References: <77f8dd75-634b-ec37-90a0-f42b242cf46c@redhat.com> <5A8359E5.3040301@oracle.com> Message-ID: <6391803c-faca-0a3d-45c4-8bda332de6ba@redhat.com> On 02/13/2018 10:34 PM, Jonathan Gibbons wrote: > I would again encourage you to be moving away from shell tests in > favor of tests written in Java. > > That is the general direction for all OpenJDK tests. Tests can be > faster, and it is certainly easier > to write and use library code in Java to handle the sort of task you > are doing here. > I would agree, that for most "normal" tests creating java jtregs is better solution, but there are sometimes "special" cases, where tests are doing things like: - building something and adding it to boot classpath etc. - calling many extenal programs ( e.g. generating openssl certificats, ? running debuging toos etc.) - running javah, gcc - using rmic - test involving java's shared archive ... where shell may be justified > -- Jon > > On 02/13/2018 07:21 AM, Zden?k ?ambersk? wrote: >> Hi, >> >> I am currently trying to make some jtreg shell tests work on modular >> jdk. >> And while TESTMODULES env. variable gives me list of required modules, >> there is still need for additional code to transform it to parameters >> for java, javac (these --add-modules, --add-exports params ). >> >> I ended up with something like this: >> >> ADD_MODULES_PARAMS="" >> ADD_EXPORTS_PARAMS="" >> if [ -n "${TESTMODULES}" ] ; then >> ??? ADD_MODULES_PARAMS="--add-modules $( printf "%s" "${TESTMODULES}" \ >> ??????? | sed >> 's/\([^/[:space:]]\+\)\(\/[^[:space:]]*\)*[[:space:]]*/\1,/g' )" >> ??? ADD_MODULES_PARAMS="${ADD_MODULES_PARAMS%,}" >> >> ??? ADD_EXPORTS_PARAMS="$( printf "%s" "${TESTMODULES}" \ >> ??????? | sed 's/[^[:space:]]\+/--add-exports &=ALL-UNNAMED/g' )" >> fi >> >> I wonder if env. variable with generated parameters >> could be passed toshell tests by environment to simplify >> shell jtreg tests for modular JDK? >> >> best regards, >> > -- Zden?k ?ambersk? OpenJDK QE Red Hat From jonathan.gibbons at oracle.com Fri Feb 23 00:15:39 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 23 Feb 2018 00:15:39 +0000 Subject: hg: code-tools/jtreg: align JDK_Version.forName with javac Message-ID: <201802230015.w1N0FdPD001063@aojmv0008.oracle.com> Changeset: b094a764d91d Author: jjg Date: 2018-02-22 16:10 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/b094a764d91d align JDK_Version.forName with javac ! src/share/classes/com/sun/javatest/regtest/agent/JDK_Version.java ! src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java From zzambers at redhat.com Mon Feb 26 16:38:47 2018 From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=) Date: Mon, 26 Feb 2018 17:38:47 +0100 Subject: jtreg JDK7 support Message-ID: <55892bf5-0747-3bf9-411c-d5ab7bf30fdc@redhat.com> Hi, I have noticed that latest build of jtreg (tip) on adoptopenjdk is not compatible with jdk7. Jtreg.jar itself has class versions compatible with JDK 7, but some dependencies require JDK >=8 (namely testng.jar and asmtools.jar). this caused some tests fail (on JDK 7) with e.g. Failed. Execution failed: `main' threw exception: java.lang.UnsupportedClassVersionError: org/testng/IReporter : Unsupported major.minor version 52.0 I tried to build jtreg myself using make/build-all.sh with JDK 7, but script complained it requires jdk8. I tried to remove this check :) , but it failed when building asmtools-7.0-b02. However page about building jtreg still mentions both JDK 7 or JDK 8 [1]. Could you please clarify what is the current status of jtreg, when it comes to JDK 7 support ? [1] http://openjdk.java.net/jtreg/build.html thank you best regards, -- Zden?k ?ambersk? OpenJDK QE Red Hat