From jpai at openjdk.org  Tue Apr  1 09:27:33 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Apr 2025 09:27:33 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
Message-ID: <Oz5sr9nFOK8PRzu7XRNNpG7OH2p3sNlGvYRqsUb9j54=.6c4d446b-3812-493c-b677-b234a83e9a48@github.com>

On Fri, 7 Mar 2025 10:45:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
> 
> 
> timeout.default.seconds=360
> 
> 
> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.

src/share/classes/com/sun/javatest/regtest/config/TestProperties.java line 280:

> 278: 
> 279:                     // add the default test timeout value in seconds
> 280:                     defaultTimeout = Duration.ofSeconds(getInt("timeout.default.seconds", 120));

Hello Christian, the `TEST.ROOT` (and `TEST.properties`) appear to follow the camel case style property names for most of the configurations https://openjdk.org/jtreg/tag-spec.html#TEST_ROOT. For example, `defaultExecMode`, `maxOutputSize` and so on. To be consistent with that, maybe we should expect this to be `defaultTimeoutSeconds` instead of `timeout.default.seconds`?

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2022491051

From jpai at openjdk.org  Tue Apr  1 09:32:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Apr 2025 09:32:37 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <SVADqduaxKhieZoKR2rlXMM6mp7sgRUAIWes8ZVUPC8=.d8493cb3-4ec2-4b02-9c20-420fdeec5a72@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <SVADqduaxKhieZoKR2rlXMM6mp7sgRUAIWes8ZVUPC8=.d8493cb3-4ec2-4b02-9c20-420fdeec5a72@github.com>
Message-ID: <hU2YxOOYmEonaN4wiyNnov6PUw4LI8CbFz7KTRzBq9I=.c6991a9a-218f-469a-81cd-3748390cb8a8@github.com>

On Mon, 10 Mar 2025 17:41:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
>> 
>> 
>> timeout.default.seconds=360
>> 
>> 
>> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.
>
> src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1131:
> 
>> 1129:     Map<String, String> getTestProperties()  {
>> 1130:         // initialize the properties with standard properties common to all tests
>> 1131:         Map<String, String> p = new TreeMap<>(params.getBasicTestProperties());
> 
> This change sorts all basic test properties by their name; keeping the insertion order was never a promise.

Does the new proposed feature of configuring a default timeout continue to work without this change to using a `TreeMap`? If yes, then I think it would be good to separate this change out from this PR.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2022499196

From cstein at openjdk.org  Tue Apr  1 09:42:17 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 1 Apr 2025 09:42:17 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <Oz5sr9nFOK8PRzu7XRNNpG7OH2p3sNlGvYRqsUb9j54=.6c4d446b-3812-493c-b677-b234a83e9a48@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <Oz5sr9nFOK8PRzu7XRNNpG7OH2p3sNlGvYRqsUb9j54=.6c4d446b-3812-493c-b677-b234a83e9a48@github.com>
Message-ID: <uXUMIVW0LYh8S3U7OXj-QsiRYuP7_4oVnlKGYMn3NjI=.a697413d-672b-45d4-886e-b45ecc9aefcb@github.com>

On Tue, 1 Apr 2025 09:24:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
>> 
>> 
>> timeout.default.seconds=360
>> 
>> 
>> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.
>
> src/share/classes/com/sun/javatest/regtest/config/TestProperties.java line 280:
> 
>> 278: 
>> 279:                     // add the default test timeout value in seconds
>> 280:                     defaultTimeout = Duration.ofSeconds(getInt("timeout.default.seconds", 120));
> 
> Hello Christian, the `TEST.ROOT` (and `TEST.properties`) appear to follow the camel case style property names for most of the configurations https://openjdk.org/jtreg/tag-spec.html#TEST_ROOT. For example, `defaultExecMode`, `maxOutputSize` and so on. To be consistent with that, maybe we should expect this to be `defaultTimeoutSeconds` instead of `timeout.default.seconds`?

It's quite a mixture already. There's also `lib.build` and `external.lib.roots` as counter examples.

The idea was to synchronize the key name with the system property exposed to tests in `RegressionScript`.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2022513148

From jpai at openjdk.org  Tue Apr  1 09:42:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Apr 2025 09:42:19 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
Message-ID: <MvIZRWAeaEAIlMmjULdO-X464FzcRqY8GovQ_0Mc-W0=.3fcdc269-82eb-4381-a76a-a36f4c1a38cf@github.com>

On Fri, 7 Mar 2025 10:45:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
> 
> 
> timeout.default.seconds=360
> 
> 
> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.

src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1178:

> 1176:         if (isTimeoutsEnabled()) {
> 1177:             long seconds = properties.getDefaultTimeout(getTestDescription().getFile()).toSeconds();
> 1178:             p.put("test.timeout.default.seconds", Long.toString(seconds));

Is this the properties that get advertised to the application's test code? I'm guessing it is because I see that the `tag-spec` documentation has been updated to mention that this property will be made available to the test code. 

Is there a reason why the test code would be interested in this default value? As far as I can see we don't expose the final evaluated timeout value nor do we expose any other default configuration values (like the `defaultExecMode`) as properties to the test code. So it might be better not to expose this at least until it is really necessary.

src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1357:

> 1355: 
> 1356:     private RegressionScript() {
> 1357:         this(null);

Does this constructor get used anywhere after this change? If yes, then we might have to add a null check at the call site where we are using the `properties` field to find the default timeout configuration value, like here https://github.com/openjdk/jtreg/pull/253/files#diff-19a61ca7f0fe24f891bee1b6b95f4ab2f740636458c9b20acff20c052aed9223R539

test/junitTrace/JupiterTimeoutTest.java line 38:

> 36:     void test() {
> 37:         String actual = System.getProperty("test.timeout.default.seconds", "-1");
> 38:         assertEquals("123", actual, "unexpected default value for timeout seconds");

It would be good to also include a test which overrides the default value in the test definition and verify that the overridden value is used. After all, that's the usage which prompted this change.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2022504451
PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2022507333
PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2022509584

From cstein at openjdk.org  Tue Apr  1 09:46:41 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 1 Apr 2025 09:46:41 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <MvIZRWAeaEAIlMmjULdO-X464FzcRqY8GovQ_0Mc-W0=.3fcdc269-82eb-4381-a76a-a36f4c1a38cf@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <MvIZRWAeaEAIlMmjULdO-X464FzcRqY8GovQ_0Mc-W0=.3fcdc269-82eb-4381-a76a-a36f4c1a38cf@github.com>
Message-ID: <FjMrfUV8EixNW2h1RtTI_lLXGEgXt7xfZej_8TkQiCs=.139e6a78-c458-4bf7-ae4d-0444022e3288@github.com>

On Tue, 1 Apr 2025 09:33:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
>> 
>> 
>> timeout.default.seconds=360
>> 
>> 
>> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.
>
> src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1178:
> 
>> 1176:         if (isTimeoutsEnabled()) {
>> 1177:             long seconds = properties.getDefaultTimeout(getTestDescription().getFile()).toSeconds();
>> 1178:             p.put("test.timeout.default.seconds", Long.toString(seconds));
> 
> Is this the properties that get advertised to the application's test code? I'm guessing it is because I see that the `tag-spec` documentation has been updated to mention that this property will be made available to the test code. 
> 
> Is there a reason why the test code would be interested in this default value? As far as I can see we don't expose the final evaluated timeout value nor do we expose any other default configuration values (like the `defaultExecMode`) as properties to the test code. So it might be better not to expose this at least until it is really necessary.

jtreg already exports the following timeout-related system property:
> `test.timeout.factor`	`TESTTIMEOUTFACTOR`	_The timeout factor to be applied to the default timeout for the test._
https://openjdk.org/jtreg/tag-spec.html#testvars

Test code and also test frameworks may want to adjust their bevaviour according both of these values. For example, having a test method-bound timeout or an assertion-based timeout makes more sense when the test author may react on the outer boundaries communicated by jtreg.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2022520892

From jvanek at openjdk.org  Tue Apr  1 12:32:37 2025
From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Tue, 1 Apr 2025 12:32:37 GMT
Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash
 testing
In-Reply-To: <m7_JOUWF242CtsSZ91cNWvF8E0XSeFdf6r8VzW_0joo=.f3a31b60-3016-4516-8cb8-4f796710965a@github.com>
References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
 <4L83ugDYlgs15DFBD1WQmPcW-JxLYF-Xebf0WfmXMkE=.6909092d-c822-4be5-a57f-c5def33b3bbb@github.com>
 <m7_JOUWF242CtsSZ91cNWvF8E0XSeFdf6r8VzW_0joo=.f3a31b60-3016-4516-8cb8-4f796710965a@github.com>
Message-ID: <rcmx5daO-2zAPldflWv6eumRnbYMn-jhLU769llS-oo=.96206499-0afc-41d0-890e-0f8c7a5c76d8@github.com>

On Mon, 24 Mar 2025 21:11:18 GMT, andrlos <duke at openjdk.org> wrote:

>> The use-case doesn't carry the weight of introducing and maintaining a SPI for arbitrary and distant test result mangling in the inards of `jtreg`. The aforementioned JUnit `TestRule` is a good example for a non-distant (think: test-local) way to influnce the result of a test in an understandable way.
>> 
>> In the light of the discussion above, I won't approve this pull request.
>> 
>> Let's discuss other approaches to achieve the goals expressed in https://bugs.openjdk.org/browse/CODETOOLS-7903519
>
> Hi @sormuras do you have any ideas about possible approach? It seems that I either lost my openjdk login or I never had one to start with.. I will try and get it while you can start the discussion there. Thanks!

@andrlos  please refresh/negotiate your openjdk jira system login. Lets continue the discussion here as sormuras required. Thaxn all!

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/235#issuecomment-2769200264

From fguallini at openjdk.org  Tue Apr  1 12:50:53 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Tue, 1 Apr 2025 12:50:53 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v4]
In-Reply-To: <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>
Message-ID: <7ZO4k9XFluGH13LtXgXbRtZ2oRPonPhFA0BYmTqRO9g=.3996fe32-445c-49b2-9f56-ef31754490ae@github.com>

On Wed, 26 Mar 2025 19:18:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
>> 
>> For first case
>> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
>> 
>> For 2nd case 
>> The library classes are compiled using @build tag and library classes are placed into some shared location.
>> 
>> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
>> 
>> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
>> 
>> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
>> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
>> test1/Test.java
>> test2/Test.java
>> with both tests having
>> 
>> @library "/"
>> @build Test
>> 
>> we are going just to have one Test class in library directory.
>> 
>> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
>> 
>> Times for tier1 execution with fix:
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
>> 
>> and before fix
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
>> 
>> The full fix might require more testing and adding testcase.
>> Please note that there are plans to work on the 
>> https://bugs.openjd...
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - doc updated
>  - regression test added

src/share/doc/javatest/regtest/tag-spec.html line 258:

> 256: as part of a compilation command explicitly naming the source files containing
> 257: those classes. The library directory is used as additional sourcepath for test compilation.
> 258: So jtreg impliitly compiles all test dependcies that are located in library directory.

a typo
Suggestion:

So jtreg implicitly compiles all test dependencies that are located in library directory.

src/share/doc/javatest/regtest/tag-spec.html line 261:

> 259: A test that relies upon library classes might contain appropriate
> 260: <code>@build</code> directives to explictily point classes to be compiled.
> 261: This might be useful when test depends on linbrary classes during runtime only.

Suggestion:

This might be useful when test depends on library classes during runtime only.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2022780535
PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2022781949

From cstein at openjdk.org  Tue Apr  1 16:04:41 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 1 Apr 2025 16:04:41 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v4]
In-Reply-To: <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>
Message-ID: <JFOOSzKe0ZQkumZUe0_BTSOMIkrWLalxnPJhxlJA-3o=.a3f6844c-db9b-4ef8-9aeb-34fc425c2122@github.com>

On Wed, 26 Mar 2025 19:18:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
>> 
>> For first case
>> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
>> 
>> For 2nd case 
>> The library classes are compiled using @build tag and library classes are placed into some shared location.
>> 
>> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
>> 
>> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
>> 
>> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
>> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
>> test1/Test.java
>> test2/Test.java
>> with both tests having
>> 
>> @library "/"
>> @build Test
>> 
>> we are going just to have one Test class in library directory.
>> 
>> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
>> 
>> Times for tier1 execution with fix:
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
>> 
>> and before fix
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
>> 
>> The full fix might require more testing and adding testcase.
>> Please note that there are plans to work on the 
>> https://bugs.openjd...
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - doc updated
>  - regression test added

I also like to see an opt-out switch for this change.

Having at least a system property to enable the old and well-known behaviour, using `absBaseClsDir`, would be a good fall-back. Such a boolean switch could later be enhanced by either an option on the `@library` tag, and/or defined in a `TEST.ROOT` or `TEST.properties` configuration files.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/256#issuecomment-2769862249

From jjg3 at pobox.com  Tue Apr  1 19:04:49 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Tue, 1 Apr 2025 12:04:49 -0700
Subject: RFR: 7902847: Class directory of a test case should be always
 used to compile a library
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <fc1d91cf-e407-49b3-ad7a-bb9fc4635b46@pobox.com>


On 3/25/25 10:52 AM, Leonid Mesnik wrote:
> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
>
> For first case
> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory.

Implicit compilation of the library classes into the test class 
directory is deplorable and should not be encourages.


>
> For 2nd case
> The library classes are compiled using @build tag and library classes are placed into some shared location.

Generally, library classes should be independent of any test classes and 
test class directory. As such, @build is the recommended way to build 
libraries.


> Class directory of a test case should be always used to compile a library
That would be an anti-pattern to be discouraged. Libraries are supposed 
to be shared between tests and as such, should not be beholden to any 
individual test class directory.

-- Jon




From jjg3 at pobox.com  Tue Apr  1 19:13:58 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Tue, 1 Apr 2025 12:13:58 -0700
Subject: RFR: 7902847: Class directory of a test case should be always
 used to compile a library
In-Reply-To: <fc1d91cf-e407-49b3-ad7a-bb9fc4635b46@pobox.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <fc1d91cf-e407-49b3-ad7a-bb9fc4635b46@pobox.com>
Message-ID: <42eae329-297b-47f0-8ec7-3fbcf32a6326@pobox.com>

It would be a worthwhile audit to examine test class directories after a 
test run to see whether any library clases have leaked into those 
directories.

A different approach would be to compile test classes with 
`-implicit:none` to ensure library classes do not leak into test class 
directories.
See 
https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#option-implicit

-- Jon


On 4/1/25 12:04 PM, Jonathan Gibbons wrote:
>
>
>> Class directory of a test case should be always used to compile a 
>> library
> That would be an anti-pattern to be discouraged. Libraries are 
> supposed to be shared between tests and as such, should not be 
> beholden to any individual test class directory.
>
> -- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jtreg-dev/attachments/20250401/0c9fea5d/attachment.htm>

From lmesnik at openjdk.org  Tue Apr  1 20:23:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Apr 2025 20:23:46 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v4]
In-Reply-To: <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>
Message-ID: <1nrwsu01ZzrZnfiCjAlUKFfK7_KfkpyAUWUmkEO471U=.caee23e5-583b-4ac5-924c-12fc12cb075a@github.com>

On Wed, 26 Mar 2025 19:18:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
>> 
>> For first case
>> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
>> 
>> For 2nd case 
>> The library classes are compiled using @build tag and library classes are placed into some shared location.
>> 
>> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
>> 
>> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
>> 
>> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
>> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
>> test1/Test.java
>> test2/Test.java
>> with both tests having
>> 
>> @library "/"
>> @build Test
>> 
>> we are going just to have one Test class in library directory.
>> 
>> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
>> 
>> Times for tier1 execution with fix:
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
>> 
>> and before fix
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
>> 
>> The full fix might require more testing and adding testcase.
>> Please note that there are plans to work on the 
>> https://bugs.openjd...
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - doc updated
>  - regression test added

Thank you for your feedback. See my comments inline. 
> _Mailing list message from [Jonathan Gibbons](mailto:jjg3 at pobox.com) on [jtreg-dev](mailto:jtreg-dev at mail.openjdk.org):_
> 
> On 3/25/25 10:52 AM, Leonid Mesnik wrote:
> 
> > The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
> > For first case
> > Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory.
> 
> Implicit compilation of the library classes into the test class directory is deplorable and should not be encourages.
> 
Most of tests are doing this already. The people are not going to add build tags if test works without them.  I don't think there is a way to encourage people to do this except by disabling implicit compilation. Even I do this once, it will be always the problematic to expect from jtreg test developers to add the build tags in new and update tests. 

> > For 2nd case
> > The library classes are compiled using @build tag and library classes are placed into some shared location.
> 
> Generally, library classes should be independent of any test classes and test class directory. As such, @build is the recommended way to build libraries.
> 
> > Class directory of a test case should be always used to compile a library
> 
> That would be an anti-pattern to be discouraged. Libraries are supposed to be shared between tests and as such, should not be beholden to any individual test class directory.

That's also that is broken for a lot of cases and since it was not restricted, the library tag might refer to mix of library and test code. 

So currently we have 2 type of libraries.
1) Shared, test-independent libraries like /test/lib that could be  shared as expected
There is an RFE to support such type of libraries separately. It might be decrease performance of single test execution for single test first time. However, it allow to better control libraries, support projects like Valhalla and also have fully incremented build. 
https://bugs.openjdk.org/browse/CODETOOLS-7903882

2)The test-mixed libraries, like "/" or "vmTesbase/"
that mix test and library code, and might even have same classes into different directories. 

Ideally, we'll get rid of them and switch to using only N known libraries, but so far need to support them without any test failures. 
So this fix is intended to do. Having feature that allow user to break the execution is not the good idea, better to have performance/disk penalty.
Requirement to always add @build for library classes is going to waste more developers time that I also prefer to avoid.

> 
> -- Jon

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/256#issuecomment-2770593566

From jpai at openjdk.org  Wed Apr  2 14:18:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Apr 2025 14:18:07 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <uXUMIVW0LYh8S3U7OXj-QsiRYuP7_4oVnlKGYMn3NjI=.a697413d-672b-45d4-886e-b45ecc9aefcb@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <Oz5sr9nFOK8PRzu7XRNNpG7OH2p3sNlGvYRqsUb9j54=.6c4d446b-3812-493c-b677-b234a83e9a48@github.com>
 <uXUMIVW0LYh8S3U7OXj-QsiRYuP7_4oVnlKGYMn3NjI=.a697413d-672b-45d4-886e-b45ecc9aefcb@github.com>
Message-ID: <ni4fnENDGJSkRFKgy9eNCWa3rcAU-9eos9F-wD4FEZc=.be4ec676-f0b3-426a-bf4c-607dcd71e370@github.com>

On Tue, 1 Apr 2025 09:38:36 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/share/classes/com/sun/javatest/regtest/config/TestProperties.java line 280:
>> 
>>> 278: 
>>> 279:                     // add the default test timeout value in seconds
>>> 280:                     defaultTimeout = Duration.ofSeconds(getInt("timeout.default.seconds", 120));
>> 
>> Hello Christian, the `TEST.ROOT` (and `TEST.properties`) appear to follow the camel case style property names for most of the configurations https://openjdk.org/jtreg/tag-spec.html#TEST_ROOT. For example, `defaultExecMode`, `maxOutputSize` and so on. To be consistent with that, maybe we should expect this to be `defaultTimeoutSeconds` instead of `timeout.default.seconds`?
>
> It's quite a mixture already. There's also `lib.build` and `external.lib.roots` as counter examples.
> 
> The idea was to synchronize the key name with the system property exposed to tests in `RegressionScript`.

I don't have a strong opinion about this naming in the `TEST.ROOT`/`TEST.properties`, because like you state it's already a mix of naming styles.

>> src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1178:
>> 
>>> 1176:         if (isTimeoutsEnabled()) {
>>> 1177:             long seconds = properties.getDefaultTimeout(getTestDescription().getFile()).toSeconds();
>>> 1178:             p.put("test.timeout.default.seconds", Long.toString(seconds));
>> 
>> Is this the properties that get advertised to the application's test code? I'm guessing it is because I see that the `tag-spec` documentation has been updated to mention that this property will be made available to the test code. 
>> 
>> Is there a reason why the test code would be interested in this default value? As far as I can see we don't expose the final evaluated timeout value nor do we expose any other default configuration values (like the `defaultExecMode`) as properties to the test code. So it might be better not to expose this at least until it is really necessary.
>
> jtreg already exports the following timeout-related system property:
>> `test.timeout.factor`	`TESTTIMEOUTFACTOR`	_The timeout factor to be applied to the default timeout for the test._
> https://openjdk.org/jtreg/tag-spec.html#testvars
> 
> Test code and also test frameworks may want to adjust their bevaviour according both of these values. For example, having a test method-bound timeout or an assertion-based timeout makes more sense when the test author may react on the outer boundaries communicated by jtreg.

Hello Christian, I had forgotten that the test timeout factor gets exposed to test code as a property. Having said that, the test timeout factor is the final determined value unlike this proposed default timeout property which is a default value and may not even be the actual timeout that's ultimately used by jtreg.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2024924990
PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2024923425

From cstein at openjdk.org  Thu Apr  3 10:46:20 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 3 Apr 2025 10:46:20 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <hU2YxOOYmEonaN4wiyNnov6PUw4LI8CbFz7KTRzBq9I=.c6991a9a-218f-469a-81cd-3748390cb8a8@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <SVADqduaxKhieZoKR2rlXMM6mp7sgRUAIWes8ZVUPC8=.d8493cb3-4ec2-4b02-9c20-420fdeec5a72@github.com>
 <hU2YxOOYmEonaN4wiyNnov6PUw4LI8CbFz7KTRzBq9I=.c6991a9a-218f-469a-81cd-3748390cb8a8@github.com>
Message-ID: <rUII9rdt7ncqe_Pn94i7phSIteb89A2c2HxITtaaJ64=.f24cdf8c-55a7-4571-8c77-683b9359ca0e@github.com>

On Tue, 1 Apr 2025 09:29:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1131:
>> 
>>> 1129:     Map<String, String> getTestProperties()  {
>>> 1130:         // initialize the properties with standard properties common to all tests
>>> 1131:         Map<String, String> p = new TreeMap<>(params.getBasicTestProperties());
>> 
>> This change sorts all basic test properties by their name; keeping the insertion order was never a promise.
>
> Does the new proposed feature of configuring a default timeout continue to work without this change to using a `TreeMap`? If yes, then I think it would be good to separate this change out from this PR.

Good point. Reverting this change.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2026723571

From cstein at openjdk.org  Thu Apr  3 10:46:20 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 3 Apr 2025 10:46:20 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <ni4fnENDGJSkRFKgy9eNCWa3rcAU-9eos9F-wD4FEZc=.be4ec676-f0b3-426a-bf4c-607dcd71e370@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <Oz5sr9nFOK8PRzu7XRNNpG7OH2p3sNlGvYRqsUb9j54=.6c4d446b-3812-493c-b677-b234a83e9a48@github.com>
 <uXUMIVW0LYh8S3U7OXj-QsiRYuP7_4oVnlKGYMn3NjI=.a697413d-672b-45d4-886e-b45ecc9aefcb@github.com>
 <ni4fnENDGJSkRFKgy9eNCWa3rcAU-9eos9F-wD4FEZc=.be4ec676-f0b3-426a-bf4c-607dcd71e370@github.com>
Message-ID: <4DZef6C0wDg8UHqPUChm7Qt3cGoovmLCgabS9fxk7uo=.5e80dfbc-221a-4025-abef-5753ecda5729@github.com>

On Wed, 2 Apr 2025 14:14:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> jtreg already exports the following timeout-related system property:
>>> `test.timeout.factor`	`TESTTIMEOUTFACTOR`	_The timeout factor to be applied to the default timeout for the test._
>> https://openjdk.org/jtreg/tag-spec.html#testvars
>> 
>> Test code and also test frameworks may want to adjust their bevaviour according both of these values. For example, having a test method-bound timeout or an assertion-based timeout makes more sense when the test author may react on the outer boundaries communicated by jtreg.
>
> Hello Christian, I had forgotten that the test timeout factor gets exposed to test code as a property. Having said that, the test timeout factor is the final determined value unlike this proposed default timeout property which is a default value and may not even be the actual timeout that's ultimately used by jtreg.

As discussed offline, this PR won't export that property. It can be done in a follow-up work.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2026727163

From cstein at openjdk.org  Thu Apr  3 18:48:16 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 3 Apr 2025 18:48:16 GMT
Subject: RFR: 7903961: Make default timeout configurable [v2]
In-Reply-To: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
Message-ID: <6dFP2hXk-9TtgeY8IPgTwzwZhirtSFaaQ5timZ8Hveo=.99ff1714-fc37-4dcc-a800-287ecf56e2ab@github.com>

> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
> 
> 
> timeout.default.seconds=360
> 
> 
> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Simplify implementation, don't expose default timeout value

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/253/files
  - new: https://git.openjdk.org/jtreg/pull/253/files/621abbb4..b9c04050

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=253&range=01
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=253&range=00-01

  Stats: 61 lines in 6 files changed: 3 ins; 55 del; 3 mod
  Patch: https://git.openjdk.org/jtreg/pull/253.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/253/head:pull/253

PR: https://git.openjdk.org/jtreg/pull/253

From jpai at openjdk.org  Fri Apr  4 01:48:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 01:48:04 GMT
Subject: RFR: 7903961: Make default timeout configurable [v2]
In-Reply-To: <6dFP2hXk-9TtgeY8IPgTwzwZhirtSFaaQ5timZ8Hveo=.99ff1714-fc37-4dcc-a800-287ecf56e2ab@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <6dFP2hXk-9TtgeY8IPgTwzwZhirtSFaaQ5timZ8Hveo=.99ff1714-fc37-4dcc-a800-287ecf56e2ab@github.com>
Message-ID: <l4VWB5ybccGqyUqgY-lTOUOHIU3wrqmV05ZXhI91HQY=.e3b49198-da88-44ac-bb20-33189486f34f@github.com>

On Thu, 3 Apr 2025 18:48:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
>> 
>> 
>> timeout.default.seconds=360
>> 
>> 
>> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify implementation, don't expose default timeout value

src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1351:

> 1349:     private final TestProperties properties;
> 1350: 
> 1351:     public RegressionScript(TestProperties properties) {

I did not notice this in the previous round, sorry, but this constructor can be `private` like the other one that previously was.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2027967296

From cstein at openjdk.org  Fri Apr  4 05:16:59 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 4 Apr 2025 05:16:59 GMT
Subject: RFR: 7903961: Make default timeout configurable [v2]
In-Reply-To: <l4VWB5ybccGqyUqgY-lTOUOHIU3wrqmV05ZXhI91HQY=.e3b49198-da88-44ac-bb20-33189486f34f@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <6dFP2hXk-9TtgeY8IPgTwzwZhirtSFaaQ5timZ8Hveo=.99ff1714-fc37-4dcc-a800-287ecf56e2ab@github.com>
 <l4VWB5ybccGqyUqgY-lTOUOHIU3wrqmV05ZXhI91HQY=.e3b49198-da88-44ac-bb20-33189486f34f@github.com>
Message-ID: <eyFsnU2GcJs7jltiCWAAnSYmsny6eR005IwU5evHmLM=.40c6254c-4143-4f8e-b960-d903a24125cf@github.com>

On Fri, 4 Apr 2025 01:45:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify implementation, don't expose default timeout value
>
> src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1351:
> 
>> 1349:     private final TestProperties properties;
>> 1350: 
>> 1351:     public RegressionScript(TestProperties properties) {
> 
> I did not notice this in the previous round, sorry, but this constructor can be `private` like the other one that previously was.

No, it has to remain `public` because it is used by `RegressionTestSuite` in the `config` package.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2028106229

From jpai at openjdk.org  Fri Apr  4 06:32:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 06:32:01 GMT
Subject: RFR: 7903961: Make default timeout configurable [v2]
In-Reply-To: <6dFP2hXk-9TtgeY8IPgTwzwZhirtSFaaQ5timZ8Hveo=.99ff1714-fc37-4dcc-a800-287ecf56e2ab@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <6dFP2hXk-9TtgeY8IPgTwzwZhirtSFaaQ5timZ8Hveo=.99ff1714-fc37-4dcc-a800-287ecf56e2ab@github.com>
Message-ID: <MgBRnTluuMEfRj3e3L2zyP-zq2N5pTubr28orurJoGk=.99efd82c-0610-4679-9c39-1b9859745b59@github.com>

On Thu, 3 Apr 2025 18:48:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
>> 
>> 
>> timeout.default.seconds=360
>> 
>> 
>> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify implementation, don't expose default timeout value

These changes look OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/253#pullrequestreview-2741897932

From jpai at openjdk.org  Fri Apr  4 06:32:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 06:32:02 GMT
Subject: RFR: 7903961: Make default timeout configurable [v2]
In-Reply-To: <eyFsnU2GcJs7jltiCWAAnSYmsny6eR005IwU5evHmLM=.40c6254c-4143-4f8e-b960-d903a24125cf@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
 <6dFP2hXk-9TtgeY8IPgTwzwZhirtSFaaQ5timZ8Hveo=.99ff1714-fc37-4dcc-a800-287ecf56e2ab@github.com>
 <l4VWB5ybccGqyUqgY-lTOUOHIU3wrqmV05ZXhI91HQY=.e3b49198-da88-44ac-bb20-33189486f34f@github.com>
 <eyFsnU2GcJs7jltiCWAAnSYmsny6eR005IwU5evHmLM=.40c6254c-4143-4f8e-b960-d903a24125cf@github.com>
Message-ID: <YBhIAf74vtkczk826lRkGCy0Gyupr_mWrzh4mdTFlQg=.dc7c791f-5a19-4731-8b22-6272712317e2@github.com>

On Fri, 4 Apr 2025 05:14:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1351:
>> 
>>> 1349:     private final TestProperties properties;
>>> 1350: 
>>> 1351:     public RegressionScript(TestProperties properties) {
>> 
>> I did not notice this in the previous round, sorry, but this constructor can be `private` like the other one that previously was.
>
> No, it has to remain `public` because it is used by `RegressionTestSuite` in the `config` package.

You are right, I missed that.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/253#discussion_r2028169488

From cstein at openjdk.org  Fri Apr  4 07:59:38 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 4 Apr 2025 07:59:38 GMT
Subject: RFR: 7903961: Make default timeout configurable [v3]
In-Reply-To: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
Message-ID: <HR0kusXUjIsmQVg3QQTgqgxvBJYGQNtEFi1oCukf5jM=.5c14367a-77c8-4540-be2b-b21d7cb7d1ab@github.com>

> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
> 
> 
> timeout.default.seconds=360
> 
> 
> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Add default timeout self-test

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/253/files
  - new: https://git.openjdk.org/jtreg/pull/253/files/b9c04050..4cc80531

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=253&range=02
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=253&range=01-02

  Stats: 160 lines in 7 files changed: 160 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jtreg/pull/253.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/253/head:pull/253

PR: https://git.openjdk.org/jtreg/pull/253

From cstein at openjdk.org  Fri Apr  4 08:23:07 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 4 Apr 2025 08:23:07 GMT
Subject: Integrated: 7903961: Make default timeout configurable
In-Reply-To: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
Message-ID: <SNY9WxC2yuHo7mbwnLZOvBDf9OP7hHj03EokYNHFdxI=.7fda57c6-65ba-40ab-a5ea-96737f055aab@github.com>

On Fri, 7 Mar 2025 10:45:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files:
> 
> 
> timeout.default.seconds=360
> 
> 
> Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.

This pull request has now been integrated.

Changeset: f4f2843c
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/f4f2843c876dc974750eabc8875de08e56bd3852
Stats:     195 lines in 10 files changed: 184 ins; 2 del; 9 mod

7903961: Make default timeout configurable

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jtreg/pull/253

From cstein at openjdk.org  Fri Apr  4 17:40:10 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 4 Apr 2025 17:40:10 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions
Message-ID: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>

Please review this change to allow an easier way to use current class name for test actions.

-------------

Commit messages:
 - Compute main class name by parsing the Java source file
 - Fix simple class name computation
 - Omit package computation
 - Add tag specification entry
 - Add tag specification entry
 - 7906981: Support easy way to use current class name for test actions

Changes: https://git.openjdk.org/jtreg/pull/257/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903981
  Stats: 48 lines in 6 files changed: 29 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jtreg/pull/257.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/257/head:pull/257

PR: https://git.openjdk.org/jtreg/pull/257

From cstein at openjdk.org  Fri Apr  4 17:50:17 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 4 Apr 2025 17:50:17 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v2]
In-Reply-To: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
Message-ID: <iNobsGhOnmyviR1blTQMJ-TQC2dZfcAWZxa6ABm_LQE=.9b0cafa0-dd82-44c8-b36b-b239cf2c41b6@github.com>

> Please review this change to allow an easier way to use current class name for test actions.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Clean up

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/257/files
  - new: https://git.openjdk.org/jtreg/pull/257/files/fa9f1ee6..a28397ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=01
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jtreg/pull/257.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/257/head:pull/257

PR: https://git.openjdk.org/jtreg/pull/257

From rriggs at openjdk.org  Fri Apr  4 18:31:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 18:31:00 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v2]
In-Reply-To: <iNobsGhOnmyviR1blTQMJ-TQC2dZfcAWZxa6ABm_LQE=.9b0cafa0-dd82-44c8-b36b-b239cf2c41b6@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <iNobsGhOnmyviR1blTQMJ-TQC2dZfcAWZxa6ABm_LQE=.9b0cafa0-dd82-44c8-b36b-b239cf2c41b6@github.com>
Message-ID: <22zcByGFChSnqehF9LJI0jqDGfugee4bdBmfW0GB-O4=.16b32ddb-5d51-48bd-a783-6d5278405adb@github.com>

On Fri, 4 Apr 2025 17:50:17 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to allow an easier way to use current class name for test actions.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up

Something in the PR topic should describe the change being proposed. (Something about smart tags and whatever...)
The edit to the tag-spec doesn't describe the rationale and solution.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/257#issuecomment-2779476264

From cstein at openjdk.org  Mon Apr  7 13:33:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 7 Apr 2025 13:33:34 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v3]
In-Reply-To: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
Message-ID: <kKn7k463rWidNHrh7MU2sq2CcPmAa_FTYLSdH-SNezU=.46d88523-a032-460e-bb72-2b81c0801dda@github.com>

> Please review this change to allow an easier way to use current class name for test actions.
> 
> Test authors usually specify the name of a test class to be run by `jtreg` 1:1 in a `@run` action directive. This PR introduces the new test property `test.main.class` and tries to initialize it with the fully-qualified class name of the test class. It is composed of the package name and and the first type name (`class`,`interface`,`enum`,`record`) found in the `.java` source file passed to `jtreg`.
> 
> Examples:
> - `@run main Test` - `@run main ${test.main.class}`
> - `@run main p.Test` - `@run main ${test.main.class}`
> 
> See also: [CODETOOLS-7902352: Support use of ${property.name} in action args](https://bugs.openjdk.org/browse/CODETOOLS-7902352)

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Add example to tag specification

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/257/files
  - new: https://git.openjdk.org/jtreg/pull/257/files/a28397ca..fe717e2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=02
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=01-02

  Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jtreg/pull/257.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/257/head:pull/257

PR: https://git.openjdk.org/jtreg/pull/257

From cstein at openjdk.org  Mon Apr  7 13:37:18 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 7 Apr 2025 13:37:18 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v2]
In-Reply-To: <22zcByGFChSnqehF9LJI0jqDGfugee4bdBmfW0GB-O4=.16b32ddb-5d51-48bd-a783-6d5278405adb@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <iNobsGhOnmyviR1blTQMJ-TQC2dZfcAWZxa6ABm_LQE=.9b0cafa0-dd82-44c8-b36b-b239cf2c41b6@github.com>
 <22zcByGFChSnqehF9LJI0jqDGfugee4bdBmfW0GB-O4=.16b32ddb-5d51-48bd-a783-6d5278405adb@github.com>
Message-ID: <Y5hS3OSkcghUxUdJrswmOcU3Bs9qHKgsGmbryYA_sdM=.6dde0f17-f16a-442e-96bb-a69a7301107d@github.com>

On Fri, 4 Apr 2025 18:28:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up
>
> Something in the PR topic should describe the change being proposed. (Something about smart tags and whatever...)
> The edit to the tag-spec doesn't describe the rationale and solution.

I amended the PR description and added an example to the tag-spec (and corrected years in copyright comments), @RogerRiggs. I'd like to keep the "rationale and solution" in the tag-spec description brief, as it is displayed with many others in a table.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/257#issuecomment-2783365239

From cstein at openjdk.org  Tue Apr  8 06:55:29 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 8 Apr 2025 06:55:29 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v4]
In-Reply-To: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
Message-ID: <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>

> Please review this change to allow an easier way to use current class name for test actions.
> 
> Test authors usually specify the name of a test class to be run by `jtreg` 1:1 in a `@run` action directive. This PR introduces the new test property `test.main.class` and tries to initialize it with the fully-qualified class name of the test class. It is composed of the package name and and the first type name (`class`,`interface`,`enum`,`record`) found in the `.java` source file passed to `jtreg`.
> 
> Examples:
> - `@run main Test` - `@run main ${test.main.class}`
> - `@run main p.Test` - `@run main ${test.main.class}`
> 
> See also: [CODETOOLS-7902352: Support use of ${property.name} in action args](https://bugs.openjdk.org/browse/CODETOOLS-7902352)

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Base main entry-point name computation on file name

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/257/files
  - new: https://git.openjdk.org/jtreg/pull/257/files/fe717e2f..f7dc697e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=03
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=02-03

  Stats: 18 lines in 1 file changed: 6 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jtreg/pull/257.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/257/head:pull/257

PR: https://git.openjdk.org/jtreg/pull/257

From lmesnik at openjdk.org  Tue Apr  8 17:45:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 8 Apr 2025 17:45:29 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v4]
In-Reply-To: <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
Message-ID: <hqWw8oqA8iMZJIFmX-5MoNBxE23QLt3LWjVmcbEZpJ4=.63601644-8676-43bd-add9-e956ced7e33d@github.com>

On Tue, 8 Apr 2025 06:55:29 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to allow an easier way to use current class name for test actions.
>> 
>> Test authors usually specify the name of a test class to be run by `jtreg` 1:1 in a `@run` action directive. This PR introduces the new test property `test.main.class` and tries to initialize it with the fully-qualified class name of the test class. It is composed of the package name and the truncated file name of `.java` source file passed to `jtreg`: `SomeTest.java` becomes `SomeTest`
>> 
>> Example for `Test.java` in the unnamed package:
>> - `@run main Test` - `@run main ${test.main.class}`
>> 
>> Example for `Test.java` declaring `package p;`:
>> - `@run main p.Test` - `@run main ${test.main.class}`
>> 
>> See also: [CODETOOLS-7902352: Support use of ${property.name} in action args](https://bugs.openjdk.org/browse/CODETOOLS-7902352)
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Base main entry-point name computation on file name

I think that fix looks good. 
The only question - does it enough information provided when jtreg can't execute expected test? Should be easy enough to correct the problem for jtreg test developer.
There are also small comments inline.

src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1184:

> 1182:                 .collect(Collectors.joining(File.pathSeparator));
> 1183:     }
> 1184: //    // where

please remove the commented code

src/share/doc/javatest/regtest/tag-spec.html line 1255:

> 1253: <td><code>test.main.class</code>
> 1254: <td><i>Not Available</i>
> 1255: <td>The computed name of the main entry-point of the current Java source file.

Might be add notes that 
1) packages are supported, based on package line
2) inner classes are not supported
3) the test fails during execution if ${test.main.class} is not found or doesn't have main() method. 
It is just a suggestion, please update as you think it would be better. No need to overload users with info.

-------------

Changes requested by lmesnik (no project role).

PR Review: https://git.openjdk.org/jtreg/pull/257#pullrequestreview-2750871570
PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2033717362
PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2033728610

From rriggs at openjdk.org  Tue Apr  8 18:55:36 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 18:55:36 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v4]
In-Reply-To: <hqWw8oqA8iMZJIFmX-5MoNBxE23QLt3LWjVmcbEZpJ4=.63601644-8676-43bd-add9-e956ced7e33d@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
 <hqWw8oqA8iMZJIFmX-5MoNBxE23QLt3LWjVmcbEZpJ4=.63601644-8676-43bd-add9-e956ced7e33d@github.com>
Message-ID: <2LG-2OFdBiamMZ7yc7gY0-GptdoWL29ynpcRJf-PB20=.31561df0-46a6-4eac-9484-06ca998c257a@github.com>

On Tue, 8 Apr 2025 17:39:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Base main entry-point name computation on file name
>
> src/share/doc/javatest/regtest/tag-spec.html line 1255:
> 
>> 1253: <td><code>test.main.class</code>
>> 1254: <td><i>Not Available</i>
>> 1255: <td>The computed name of the main entry-point of the current Java source file.
> 
> Might be add notes that 
> 1) packages are supported, based on package line
> 2) inner classes are not supported
> 3) the test fails during execution if ${test.main.class} is not found or doesn't have main() method. 
> It is just a suggestion, please update as you think it would be better. No need to overload users with info.

The error message produced when the executable can't be found should be very helpful.
Not specific to .java or the smart tag though.

On a similar typo, I got.
`TEST RESULT: Error. can't find FilePermissionTestX in test directory or libraries`
If it is a class name, it would be useful to say its a "class".

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2033848129

From rriggs at openjdk.org  Tue Apr  8 18:55:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 18:55:35 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v4]
In-Reply-To: <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
Message-ID: <Muc5hakugS_mHbvAyF5nuc2lGtyTitmkk_LscY6NCHs=.7ed42183-1d1d-4fed-a4ac-bb6ba8cb18e3@github.com>

On Tue, 8 Apr 2025 06:55:29 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to allow an easier way to use current class name for test actions.
>> 
>> Test authors usually specify the name of a test class to be run by `jtreg` 1:1 in a `@run` action directive. This PR introduces the new test property `test.main.class` and tries to initialize it with the fully-qualified class name of the test class. It is composed of the package name and the truncated file name of `.java` source file passed to `jtreg`: `SomeTest.java` becomes `SomeTest`
>> 
>> Example for `Test.java` in the unnamed package:
>> - `@run main Test` - `@run main ${test.main.class}`
>> 
>> Example for `Test.java` declaring `package p;`:
>> - `@run main p.Test` - `@run main ${test.main.class}`
>> 
>> See also: [CODETOOLS-7902352: Support use of ${property.name} in action args](https://bugs.openjdk.org/browse/CODETOOLS-7902352)
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Base main entry-point name computation on file name

src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1202:

> 1200:             String packageName = packageMatcher.find() ? packageMatcher.group(1) + "." : "";
> 1201:             return Optional.of(packageName + className);
> 1202:         } catch (IOException ignored) {

I think you can use "_" for the variable when its ignored, that seems to be the new convention (maybe only elsewhere) for unused variable.

test/smartActionArgs/optAuto/p/Test3.java line 35:

> 33: 
> 34: public class Test3 {
> 35:     private static final boolean expectDollar = false; // opt-auto, i.e. in

What is this for?

test/smartActionArgs/optAuto/p/Test3.java line 47:

> 45:                 case "--test.src":
> 46:                 case "--test.classes":
> 47:                 case "--test.class.path":

Command line options with "." look pretty odd, they can be mistaken for source files.
Typically, the embedded delimiter is "-" (hyphen).  Though jtreg may have its own convention.

The command line (@run) for the test only checks the first of these.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2033825894
PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2033839401
PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2033833844

From cstein at openjdk.org  Wed Apr  9 05:59:53 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 9 Apr 2025 05:59:53 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v4]
In-Reply-To: <Muc5hakugS_mHbvAyF5nuc2lGtyTitmkk_LscY6NCHs=.7ed42183-1d1d-4fed-a4ac-bb6ba8cb18e3@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
 <Muc5hakugS_mHbvAyF5nuc2lGtyTitmkk_LscY6NCHs=.7ed42183-1d1d-4fed-a4ac-bb6ba8cb18e3@github.com>
Message-ID: <kGfYUiuc3vx6Z8IFDeJHx7N0IJrXvafJpJVhCW2Tl3c=.f85abee6-e747-455c-a089-084004754ef0@github.com>

On Tue, 8 Apr 2025 18:36:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Base main entry-point name computation on file name
>
> src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1202:
> 
>> 1200:             String packageName = packageMatcher.find() ? packageMatcher.group(1) + "." : "";
>> 1201:             return Optional.of(packageName + className);
>> 1202:         } catch (IOException ignored) {
> 
> I think you can use "_" for the variable when its ignored, that seems to be the new convention (maybe only elsewhere) for unused variable.

As the base line of `jtreg` is still Java 11, we cannot use a single `_` to express intentionally unused variables.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2034501716

From cstein at openjdk.org  Wed Apr  9 06:07:56 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 9 Apr 2025 06:07:56 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v4]
In-Reply-To: <hqWw8oqA8iMZJIFmX-5MoNBxE23QLt3LWjVmcbEZpJ4=.63601644-8676-43bd-add9-e956ced7e33d@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
 <hqWw8oqA8iMZJIFmX-5MoNBxE23QLt3LWjVmcbEZpJ4=.63601644-8676-43bd-add9-e956ced7e33d@github.com>
Message-ID: <zdlm3mFPBIteaNav7ztwdKAKBVouRSkaSf_zy-BaGnI=.352713f4-382e-4c22-98aa-c3b369eec986@github.com>

On Tue, 8 Apr 2025 17:32:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Base main entry-point name computation on file name
>
> src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java line 1184:
> 
>> 1182:                 .collect(Collectors.joining(File.pathSeparator));
>> 1183:     }
>> 1184: //    // where
> 
> please remove the commented code

Done.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2034510171

From cstein at openjdk.org  Wed Apr  9 06:07:56 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 9 Apr 2025 06:07:56 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v4]
In-Reply-To: <Muc5hakugS_mHbvAyF5nuc2lGtyTitmkk_LscY6NCHs=.7ed42183-1d1d-4fed-a4ac-bb6ba8cb18e3@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
 <Muc5hakugS_mHbvAyF5nuc2lGtyTitmkk_LscY6NCHs=.7ed42183-1d1d-4fed-a4ac-bb6ba8cb18e3@github.com>
Message-ID: <w4RUz4iu3c7eILHyjcRP9Vogh14Nf76vHd_atCvFYWc=.5389b98a-fc70-468a-9add-94e22800c0da@github.com>

On Tue, 8 Apr 2025 18:45:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Base main entry-point name computation on file name
>
> test/smartActionArgs/optAuto/p/Test3.java line 35:
> 
>> 33: 
>> 34: public class Test3 {
>> 35:     private static final boolean expectDollar = false; // opt-auto, i.e. in
> 
> What is this for?

Will be removed.

> test/smartActionArgs/optAuto/p/Test3.java line 47:
> 
>> 45:                 case "--test.src":
>> 46:                 case "--test.classes":
>> 47:                 case "--test.class.path":
> 
> Command line options with "." look pretty odd, they can be mistaken for source files.
> Typically, the embedded delimiter is "-" (hyphen).  Though jtreg may have its own convention.
> 
> The command line (@run) for the test only checks the first of these.

The `Test3.java` file is an almost 1:1 copy of the existing `Test.java` file in the parent directory. The conventions and assertions are inherited; with their original reasoning.

As those aren't interesting here, I'll reduce the logic of this new test to an empty `main()` method block. We only care for the correct expansion of `${test.main.class}` resulting in invoking the associated program.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2034509364
PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2034509167

From cstein at openjdk.org  Wed Apr  9 08:30:07 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 9 Apr 2025 08:30:07 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v5]
In-Reply-To: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
Message-ID: <C3Nyi__5AHAqH1Or7lRB0qcxeYGIX08raf5wgLR4_9c=.5c879b77-7d7d-4352-9f50-e04b2fd63c42@github.com>

> Please review this change to allow an easier way to use current class name for test actions.
> 
> Test authors usually specify the name of a test class to be run by `jtreg` 1:1 in a `@run` action directive. This PR introduces the new test property `test.main.class` and tries to initialize it with the fully-qualified class name of the test class. It is composed of the package name and the truncated file name of `.java` source file passed to `jtreg`: `SomeTest.java` becomes `SomeTest`
> 
> Example for `Test.java` in the unnamed package:
> - `@run main Test` - `@run main ${test.main.class}`
> 
> Example for `Test.java` declaring `package p;`:
> - `@run main p.Test` - `@run main ${test.main.class}`
> 
> See also: [CODETOOLS-7902352: Support use of ${property.name} in action args](https://bugs.openjdk.org/browse/CODETOOLS-7902352)

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/257/files
  - new: https://git.openjdk.org/jtreg/pull/257/files/f7dc697e..a2f950c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=04
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=03-04

  Stats: 189 lines in 7 files changed: 118 ins; 67 del; 4 mod
  Patch: https://git.openjdk.org/jtreg/pull/257.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/257/head:pull/257

PR: https://git.openjdk.org/jtreg/pull/257

From cstein at openjdk.org  Wed Apr  9 08:30:07 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 9 Apr 2025 08:30:07 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v4]
In-Reply-To: <2LG-2OFdBiamMZ7yc7gY0-GptdoWL29ynpcRJf-PB20=.31561df0-46a6-4eac-9484-06ca998c257a@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <tEov_bSqLjhDYB9yh4Pcpvtk2xzNMxwIgHxNnh1K-zo=.ebe5b29d-7f06-4a01-9144-0a67d661ce47@github.com>
 <hqWw8oqA8iMZJIFmX-5MoNBxE23QLt3LWjVmcbEZpJ4=.63601644-8676-43bd-add9-e956ced7e33d@github.com>
 <2LG-2OFdBiamMZ7yc7gY0-GptdoWL29ynpcRJf-PB20=.31561df0-46a6-4eac-9484-06ca998c257a@github.com>
Message-ID: <KbNlxEtzHLHqCxlt5MWr4FRVyuH4OFH6ew0lKroUPPQ=.25b7cf2c-a3ca-4d46-8df0-375c02edcb6b@github.com>

On Tue, 8 Apr 2025 18:52:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/share/doc/javatest/regtest/tag-spec.html line 1255:
>> 
>>> 1253: <td><code>test.main.class</code>
>>> 1254: <td><i>Not Available</i>
>>> 1255: <td>The computed name of the main entry-point of the current Java source file.
>> 
>> Might be add notes that 
>> 1) packages are supported, based on package line
>> 2) inner classes are not supported
>> 3) the test fails during execution if ${test.main.class} is not found or doesn't have main() method. 
>> It is just a suggestion, please update as you think it would be better. No need to overload users with info.
>
> The error message produced when the executable can't be found should be very helpful.
> Not specific to .java or the smart tag though.
> 
> On a similar typo, I got.
> `TEST RESULT: Error. can't find FilePermissionTestX in test directory or libraries`
> If it is a class name, it would be useful to say its a "class".

Refined the documentation. A more helpful error message would require a deeper knowledge of the setup at the time of the name computation. It is up to the test author to either specify a hard-coded fully-qualified class name as of now; or ensure the heuristic based on the file name is matched.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/257#discussion_r2034776156

From cstein at openjdk.org  Mon Apr 14 13:13:46 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 14 Apr 2025 13:13:46 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v6]
In-Reply-To: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
Message-ID: <bOT_JvqbdQqzNOGQqbd14_BFshrD6K04wJKbbJr3q5c=.65620549-2e0b-43cd-823f-2e78e5564c03@github.com>

> Please review this change to allow an easier way to use current class name for test actions.
> 
> Test authors usually specify the name of a test class to be run by `jtreg` 1:1 in a `@run` action directive. This PR introduces the new test property `test.main.class` and tries to initialize it with the fully-qualified class name of the test class. It is composed of the package name and the truncated file name of `.java` source file passed to `jtreg`: `SomeTest.java` becomes `SomeTest`
> 
> Example for `Test.java` in the unnamed package:
> - `@run main Test` - `@run main ${test.main.class}`
> 
> Example for `Test.java` declaring `package p;`:
> - `@run main p.Test` - `@run main ${test.main.class}`
> 
> See also: [CODETOOLS-7902352: Support use of ${property.name} in action args](https://bugs.openjdk.org/browse/CODETOOLS-7902352)

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Use canonical expression for expecting non-zero result

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/257/files
  - new: https://git.openjdk.org/jtreg/pull/257/files/a2f950c0..fee34761

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=05
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=257&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/257.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/257/head:pull/257

PR: https://git.openjdk.org/jtreg/pull/257

From cstein at openjdk.org  Mon Apr 14 16:32:59 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 14 Apr 2025 16:32:59 GMT
Subject: RFR: 7903988: IDEA plugin: temp directories don't work on Windows
In-Reply-To: <nGELtc5c4A04A56IXjj58dCe6DoGrnTNGrWDiMea67E=.5b03ed2b-068f-47d8-839a-5a89d2885837@github.com>
References: <nGELtc5c4A04A56IXjj58dCe6DoGrnTNGrWDiMea67E=.5b03ed2b-068f-47d8-839a-5a89d2885837@github.com>
Message-ID: <u_zD3ohZF2keDtGDji5CVi-3kyTcLxWFDK_Rl5i84hA=.ff8e622d-7a9f-4317-aaa1-cd75a0543e53@github.com>

On Sat, 12 Apr 2025 18:21:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Copied from the JBS issue:
> 
> To find the temporary directory on Windows, one of the environment variables `TMP`, `TEMP`, or `USERPROFILE` is needed [1](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha#remarks). If these are not set, `C:\WINDOWS` is used as a fallback, but this directory is typically inaccessible (and generally not really a directory you want to leave temp files in).
> 
> The IDEA plugin currently doesn't forward these variables to the jtreg process that it starts, resulting in them being unset. For tests that e.g. create temporary files or directories, this result in an `AccessDeniedException` such as:
> 
> 
> java.nio.file.AccessDeniedException: C:\\WINDOWS\\asdf12599356154200781179
>   at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
>   at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
>   at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
>   at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:231)
>   at java.base/java.nio.file.Files.newByteChannel(Files.java:357)
>   at java.base/java.nio.file.Files.createFile(Files.java:609)
>   at java.base/java.nio.file.TempFileHelper.create(TempFileHelper.java:132)
>   at java.base/java.nio.file.TempFileHelper.createTempFile(TempFileHelper.java:150)
>   at java.base/java.nio.file.Files.createTempFile(Files.java:842)
>   at TestTempDir.testTempDir(TestTempDir.java:39)
> 
> 
> The plugin should forward these environment variables on Windows, to make sure that the temporary directory can be found by tests.
> 
> Tested locally with a simple test that calls [`Files::createTempFile`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...)), and checked that these changes prevent an `AccessDeniedError` from being thrown.

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/JTRegConfigurationRunnableState.java line 41:

> 39: import com.intellij.openapi.module.Module;
> 40: import com.intellij.util.PathUtil;
> 41: import com.oracle.plugin.jtreg.util.JTRegUtils;

Nit: please move this line to the other `com.oracle.plugin.jtreg...` imports.

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/JTRegConfigurationRunnableState.java line 111:

> 109:         javaParameters.setMainClass("com.sun.javatest.regtest.Main");
> 110: 
> 111:         if (JTRegUtils.IS_WINDOWS) {

What happens if `System.getenv("TMP")` returns `null`?

Wouldn't it be better to check that first for each pair, and if the value is non-null, add the pair to the  `javaParameters` instance?

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/258#discussion_r2042497165
PR Review Comment: https://git.openjdk.org/jtreg/pull/258#discussion_r2042500219

From lmesnik at openjdk.org  Mon Apr 14 17:53:09 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 14 Apr 2025 17:53:09 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v5]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <eOiRelBzXUO6UA7LybuGih0OFcwT3t7VHCjvGSglc-A=.204e9345-8670-4c21-a27a-f790baf484f3@github.com>

> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
> 
> For first case
> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
> 
> For 2nd case 
> The library classes are compiled using @build tag and library classes are placed into some shared location.
> 
> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
> 
> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
> 
> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
> test1/Test.java
> test2/Test.java
> with both tests having
> 
> @library "/"
> @build Test
> 
> we are going just to have one Test class in library directory.
> 
> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
> 
> Times for tier1 execution with fix:
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
> 
> and before fix
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
> 
> The full fix might require more testing and adding testcase.
> Please note that there are plans to work on the 
> https://bugs.openjdk.org/browse/CODETOOLS-7903882
> and
> https://bugs.openjdk.org/browse/JDK-8346058
> So ...

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - the propery was added to revert sharing of libraries
 - typo fxied

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/532981df..42b188e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=04
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=03-04

  Stats: 36 lines in 4 files changed: 29 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jtreg/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/256/head:pull/256

PR: https://git.openjdk.org/jtreg/pull/256

From jvernee at openjdk.org  Mon Apr 14 18:03:04 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 14 Apr 2025 18:03:04 GMT
Subject: RFR: 7903988: IDEA plugin: temp directories don't work on Windows
In-Reply-To: <u_zD3ohZF2keDtGDji5CVi-3kyTcLxWFDK_Rl5i84hA=.ff8e622d-7a9f-4317-aaa1-cd75a0543e53@github.com>
References: <nGELtc5c4A04A56IXjj58dCe6DoGrnTNGrWDiMea67E=.5b03ed2b-068f-47d8-839a-5a89d2885837@github.com>
 <u_zD3ohZF2keDtGDji5CVi-3kyTcLxWFDK_Rl5i84hA=.ff8e622d-7a9f-4317-aaa1-cd75a0543e53@github.com>
Message-ID: <MnqRn6RQn2sGikfvFLnflVd_Hp1BBZh2a0Qi4eqQE9g=.4396b1ad-0781-4fe7-91c5-5747d5d4f1bd@github.com>

On Mon, 14 Apr 2025 16:30:25 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Copied from the JBS issue:
>> 
>> To find the temporary directory on Windows, one of the environment variables `TMP`, `TEMP`, or `USERPROFILE` is needed [1](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha#remarks). If these are not set, `C:\WINDOWS` is used as a fallback, but this directory is typically inaccessible (and generally not really a directory you want to leave temp files in).
>> 
>> The IDEA plugin currently doesn't forward these variables to the jtreg process that it starts, resulting in them being unset. For tests that e.g. create temporary files or directories, this result in an `AccessDeniedException` such as:
>> 
>> 
>> java.nio.file.AccessDeniedException: C:\\WINDOWS\\asdf12599356154200781179
>>   at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
>>   at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
>>   at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
>>   at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:231)
>>   at java.base/java.nio.file.Files.newByteChannel(Files.java:357)
>>   at java.base/java.nio.file.Files.createFile(Files.java:609)
>>   at java.base/java.nio.file.TempFileHelper.create(TempFileHelper.java:132)
>>   at java.base/java.nio.file.TempFileHelper.createTempFile(TempFileHelper.java:150)
>>   at java.base/java.nio.file.Files.createTempFile(Files.java:842)
>>   at TestTempDir.testTempDir(TestTempDir.java:39)
>> 
>> 
>> The plugin should forward these environment variables on Windows, to make sure that the temporary directory can be found by tests.
>> 
>> Tested locally with a simple test that calls [`Files::createTempFile`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...)), and checked that these changes prevent an `AccessDeniedError` from being thrown.
>
> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/JTRegConfigurationRunnableState.java line 111:
> 
>> 109:         javaParameters.setMainClass("com.sun.javatest.regtest.Main");
>> 110: 
>> 111:         if (JTRegUtils.IS_WINDOWS) {
> 
> What happens if `System.getenv("TMP")` returns `null`?
> 
> Wouldn't it be better to check that first for each pair, and if the value is non-null, add the pair to the  `javaParameters` instance?

That's probably better yeah. I was assuming the value would just be ignored if null. The implementation of `addEnv` just adds the value to a map.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/258#discussion_r2042643569

From lmesnik at openjdk.org  Mon Apr 14 18:59:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 14 Apr 2025 18:59:15 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v6]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <KV6wOXin1s0FQk53-GcEcR1J901QRNmfAQ3MWR0YFxU=.3ff4afa8-a02f-4723-956d-8573f1510866@github.com>

> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
> 
> For first case
> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
> 
> For 2nd case 
> The library classes are compiled using @build tag and library classes are placed into some shared location.
> 
> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
> 
> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
> 
> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
> test1/Test.java
> test2/Test.java
> with both tests having
> 
> @library "/"
> @build Test
> 
> we are going just to have one Test class in library directory.
> 
> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
> 
> Times for tier1 execution with fix:
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
> 
> and before fix
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
> 
> The full fix might require more testing and adding testcase.
> Please note that there are plans to work on the 
> https://bugs.openjdk.org/browse/CODETOOLS-7903882
> and
> https://bugs.openjdk.org/browse/JDK-8346058
> So ...

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  incorrectly updated var

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/42b188e6..cfe6aecb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=05
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/256/head:pull/256

PR: https://git.openjdk.org/jtreg/pull/256

From lmesnik at openjdk.org  Mon Apr 14 21:03:33 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 14 Apr 2025 21:03:33 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v7]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <nEsnXO39N_A5EkA8It0ztcBvmAgcIUmPln26BFpej0Y=.001572a4-a2ce-4ab9-8cc6-d9eeadd360dc@github.com>

> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
> 
> For first case
> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
> 
> For 2nd case 
> The library classes are compiled using @build tag and library classes are placed into some shared location.
> 
> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
> 
> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
> 
> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
> test1/Test.java
> test2/Test.java
> with both tests having
> 
> @library "/"
> @build Test
> 
> we are going just to have one Test class in library directory.
> 
> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
> 
> Times for tier1 execution with fix:
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
> 
> and before fix
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
> 
> The full fix might require more testing and adding testcase.
> Please note that there are plans to work on the 
> https://bugs.openjdk.org/browse/CODETOOLS-7903882
> and
> https://bugs.openjdk.org/browse/JDK-8346058
> So ...

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  added test for legacy option

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/cfe6aecb..4d275a77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=06
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=05-06

  Stats: 30 lines in 1 file changed: 22 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jtreg/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/256/head:pull/256

PR: https://git.openjdk.org/jtreg/pull/256

From lmesnik at openjdk.org  Tue Apr 15 01:08:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Apr 2025 01:08:53 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v6]
In-Reply-To: <bOT_JvqbdQqzNOGQqbd14_BFshrD6K04wJKbbJr3q5c=.65620549-2e0b-43cd-823f-2e78e5564c03@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <bOT_JvqbdQqzNOGQqbd14_BFshrD6K04wJKbbJr3q5c=.65620549-2e0b-43cd-823f-2e78e5564c03@github.com>
Message-ID: <5YipAo9-Bw56h2td2rUhsHuGhOyJOrgXf6ZCSSnav9c=.338d05ce-294d-4af6-9009-30677d17c6fc@github.com>

On Mon, 14 Apr 2025 13:13:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to allow an easier way to use current class name for test actions.
>> 
>> Test authors usually specify the name of a test class to be run by `jtreg` 1:1 in a `@run` action directive. This PR introduces the new test property `test.main.class` and tries to initialize it with the fully-qualified class name of the test class. It is composed of the package name and the truncated file name of `.java` source file passed to `jtreg`: `SomeTest.java` becomes `SomeTest`
>> 
>> Example for `Test.java` in the unnamed package:
>> - `@run main Test` - `@run main ${test.main.class}`
>> 
>> Example for `Test.java` declaring `package p;`:
>> - `@run main p.Test` - `@run main ${test.main.class}`
>> 
>> See also: [CODETOOLS-7902352: Support use of ${property.name} in action args](https://bugs.openjdk.org/browse/CODETOOLS-7902352)
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical expression for expecting non-zero result

Changes looks good.

-------------

Marked as reviewed by lmesnik (no project role).

PR Review: https://git.openjdk.org/jtreg/pull/257#pullrequestreview-2766197423

From cstein at openjdk.org  Tue Apr 15 14:56:41 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Apr 2025 14:56:41 GMT
Subject: RFR: 7903989: Default to no error if existing,
 make parent directories as needed
Message-ID: <_2_NEz0Tado4gaUJUiE2oqVf77iYch0sp1floUC95lY=.9cc1d0db-eefd-4762-8280-cf9ece6ab90d@github.com>

Prior this change, most usages of the `$(MKDIR)` variable in jtreg's self-tests had to add `-p` in order to not fail with an "error if existing, make parent directories as needed". Many usages are lacking the flag and in concurrent test scenarios, this leads to flaky tests.

This PR appends `-p` to each expansion of `$(MKDIR)`. Hard-coded `-p` will be removed; stray/duplicate `-p` flag don't seem to be a problem for `mkdir`'s option parser. I didn't see any "-p specifed more than once" warnings.

This PR also cleans up redundant `-f` and `-rf` arguments from `$(RM) ...` calls, as they are very close in nature and location of the `$(MKDIR)` calls, as `Defs.gmk` declares `RM` to expand with `-rf`.

-------------

Commit messages:
 - Remove redundant `-rf` flags
 - Touch copyright year
 - Remove redundant `-f` flags, `$(RM)` already comes with `-rf`
 - Remove redundant `-p` flags
 - Default to no error if existing, make parent directories as needed

Changes: https://git.openjdk.org/jtreg/pull/259/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=259&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903989
  Stats: 156 lines in 50 files changed: 0 ins; 0 del; 156 mod
  Patch: https://git.openjdk.org/jtreg/pull/259.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/259/head:pull/259

PR: https://git.openjdk.org/jtreg/pull/259

From iris at openjdk.org  Tue Apr 15 14:56:42 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 15 Apr 2025 14:56:42 GMT
Subject: RFR: 7903989: Default to no error if existing,
 make parent directories as needed
In-Reply-To: <_2_NEz0Tado4gaUJUiE2oqVf77iYch0sp1floUC95lY=.9cc1d0db-eefd-4762-8280-cf9ece6ab90d@github.com>
References: <_2_NEz0Tado4gaUJUiE2oqVf77iYch0sp1floUC95lY=.9cc1d0db-eefd-4762-8280-cf9ece6ab90d@github.com>
Message-ID: <JYT8vS-obDNbJd4V2E8gu0BKsrMXVuZ9xwGxb38pQDA=.32806b2b-65fe-493a-bb53-578bd03ad24f@github.com>

On Mon, 14 Apr 2025 15:44:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prior this change, most usages of the `$(MKDIR)` variable in jtreg's self-tests had to add `-p` in order to not fail with an "error if existing, make parent directories as needed". Many usages are lacking the flag and in concurrent test scenarios, this leads to flaky tests.
> 
> This PR appends `-p` to each expansion of `$(MKDIR)`. Hard-coded `-p` will be removed; stray/duplicate `-p` flag don't seem to be a problem for `mkdir`'s option parser. I didn't see any "-p specifed more than once" warnings.
> 
> This PR also cleans up redundant `-f` and `-rf` arguments from `$(RM) ...` calls, as they are very close in nature and location of the `$(MKDIR)` calls, as `Defs.gmk` declares `RM` to expand with `-rf`.

I appreciate the cleanup for `$(RM)`.

Thanks.

Marked as reviewed by iris (Reviewer).

test/jdkOptsTest/JDKOptsTest.gmk line 38:

> 36: 		-Xlint -Werror \
> 37: 		-encoding ASCII $(TESTDIR)/jdkOptsTest/JDKOptsTest.java
> 38: 	$(RM) -rf $(@:%.ok=%)/tmp

`$(RM)` is already defined to include the `-rf`, so suggest you remove those options here

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/259#pullrequestreview-2768497543
PR Review: https://git.openjdk.org/jtreg/pull/259#pullrequestreview-2768741570
PR Review Comment: https://git.openjdk.org/jtreg/pull/259#discussion_r2044679365

From cstein at openjdk.org  Tue Apr 15 14:56:43 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Apr 2025 14:56:43 GMT
Subject: RFR: 7903989: Default to no error if existing,
 make parent directories as needed
In-Reply-To: <JYT8vS-obDNbJd4V2E8gu0BKsrMXVuZ9xwGxb38pQDA=.32806b2b-65fe-493a-bb53-578bd03ad24f@github.com>
References: <_2_NEz0Tado4gaUJUiE2oqVf77iYch0sp1floUC95lY=.9cc1d0db-eefd-4762-8280-cf9ece6ab90d@github.com>
 <JYT8vS-obDNbJd4V2E8gu0BKsrMXVuZ9xwGxb38pQDA=.32806b2b-65fe-493a-bb53-578bd03ad24f@github.com>
Message-ID: <0nbr0pNvCZAiHrKz29BfqiHvdIEMK47udnDorVp6eNU=.2676510d-9849-431b-bd6a-8209a392b3e9@github.com>

On Tue, 15 Apr 2025 14:12:38 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Prior this change, most usages of the `$(MKDIR)` variable in jtreg's self-tests had to add `-p` in order to not fail with an "error if existing, make parent directories as needed". Many usages are lacking the flag and in concurrent test scenarios, this leads to flaky tests.
>> 
>> This PR appends `-p` to each expansion of `$(MKDIR)`. Hard-coded `-p` will be removed; stray/duplicate `-p` flag don't seem to be a problem for `mkdir`'s option parser. I didn't see any "-p specifed more than once" warnings.
>> 
>> This PR also cleans up redundant `-f` and `-rf` arguments from `$(RM) ...` calls, as they are very close in nature and location of the `$(MKDIR)` calls, as `Defs.gmk` declares `RM` to expand with `-rf`.
>
> test/jdkOptsTest/JDKOptsTest.gmk line 38:
> 
>> 36: 		-Xlint -Werror \
>> 37: 		-encoding ASCII $(TESTDIR)/jdkOptsTest/JDKOptsTest.java
>> 38: 	$(RM) -rf $(@:%.ok=%)/tmp
> 
> `$(RM)` is already defined to include the `-rf`, so suggest you remove those options here

Good catch. I only searched for `$(RM) -f` patterns before. Searching for `$(RM) -rf` hit two locations, both addressed in https://github.com/openjdk/jtreg/pull/259/commits/167328701a7f253b0eadbfe638545063fb217e5e

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/259#discussion_r2044800640

From cstein at openjdk.org  Tue Apr 15 14:56:43 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Apr 2025 14:56:43 GMT
Subject: RFR: 7903989: Default to no error if existing,
 make parent directories as needed
In-Reply-To: <0nbr0pNvCZAiHrKz29BfqiHvdIEMK47udnDorVp6eNU=.2676510d-9849-431b-bd6a-8209a392b3e9@github.com>
References: <_2_NEz0Tado4gaUJUiE2oqVf77iYch0sp1floUC95lY=.9cc1d0db-eefd-4762-8280-cf9ece6ab90d@github.com>
 <JYT8vS-obDNbJd4V2E8gu0BKsrMXVuZ9xwGxb38pQDA=.32806b2b-65fe-493a-bb53-578bd03ad24f@github.com>
 <0nbr0pNvCZAiHrKz29BfqiHvdIEMK47udnDorVp6eNU=.2676510d-9849-431b-bd6a-8209a392b3e9@github.com>
Message-ID: <760dAN1Ju3b5uydhCnH0IFTmx68VwUCe1IaCNeWIudU=.edd4d74a-c4fb-4452-beca-41ed5ac53dbc@github.com>

On Tue, 15 Apr 2025 14:43:13 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> test/jdkOptsTest/JDKOptsTest.gmk line 38:
>> 
>>> 36: 		-Xlint -Werror \
>>> 37: 		-encoding ASCII $(TESTDIR)/jdkOptsTest/JDKOptsTest.java
>>> 38: 	$(RM) -rf $(@:%.ok=%)/tmp
>> 
>> `$(RM)` is already defined to include the `-rf`, so suggest you remove those options here
>
> Good catch. I only searched for `$(RM) -f` patterns before. Searching for `$(RM) -rf` hit two locations, both addressed in https://github.com/openjdk/jtreg/pull/259/commits/167328701a7f253b0eadbfe638545063fb217e5e

By the way, no hits for `$(RM) -fr` ... ?

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/259#discussion_r2044804160

From cstein at openjdk.org  Tue Apr 15 15:02:13 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Apr 2025 15:02:13 GMT
Subject: Integrated: 7903989: Default to no error if existing,
 make parent directories as needed
In-Reply-To: <_2_NEz0Tado4gaUJUiE2oqVf77iYch0sp1floUC95lY=.9cc1d0db-eefd-4762-8280-cf9ece6ab90d@github.com>
References: <_2_NEz0Tado4gaUJUiE2oqVf77iYch0sp1floUC95lY=.9cc1d0db-eefd-4762-8280-cf9ece6ab90d@github.com>
Message-ID: <s15QPYoFpWHe0ayiqOXuTdpvntqwZHVTBkuz8a8iH-s=.8aac14d8-fbde-4b9e-b767-550d02e53f90@github.com>

On Mon, 14 Apr 2025 15:44:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prior this change, most usages of the `$(MKDIR)` variable in jtreg's self-tests had to add `-p` in order to not fail with an "error if existing, make parent directories as needed". Many usages are lacking the flag and in concurrent test scenarios, this leads to flaky tests.
> 
> This PR appends `-p` to each expansion of `$(MKDIR)`. Hard-coded `-p` will be removed; stray/duplicate `-p` flag don't seem to be a problem for `mkdir`'s option parser. I didn't see any "-p specifed more than once" warnings.
> 
> This PR also cleans up redundant `-f` and `-rf` arguments from `$(RM) ...` calls, as they are very close in nature and location of the `$(MKDIR)` calls, as `Defs.gmk` declares `RM` to expand with `-rf`.

This pull request has now been integrated.

Changeset: 19cdb840
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/19cdb8404930c3025bd48436907ccc65bd133fee
Stats:     156 lines in 50 files changed: 0 ins; 0 del; 156 mod

7903989: Default to no error if existing, make parent directories as needed

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jtreg/pull/259

From cstein at openjdk.org  Tue Apr 15 15:35:03 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Apr 2025 15:35:03 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v4]
In-Reply-To: <7ZO4k9XFluGH13LtXgXbRtZ2oRPonPhFA0BYmTqRO9g=.3996fe32-445c-49b2-9f56-ef31754490ae@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>
 <7ZO4k9XFluGH13LtXgXbRtZ2oRPonPhFA0BYmTqRO9g=.3996fe32-445c-49b2-9f56-ef31754490ae@github.com>
Message-ID: <iCJ6Ie-_8qe4aKZtiUfvXt78VHbRFe7_jMhKfhVYcQI=.b0663fcd-6aa1-45f1-9850-a33bbbfc24c5@github.com>

On Tue, 1 Apr 2025 12:44:20 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - doc updated
>>  - regression test added
>
> src/share/doc/javatest/regtest/tag-spec.html line 261:
> 
>> 259: A test that relies upon library classes might contain appropriate
>> 260: <code>@build</code> directives to explictily point classes to be compiled.
>> 261: This might be useful when test depends on linbrary classes during runtime only.
> 
> Suggestion:
> 
> This might be useful when test depends on library classes during runtime only.

@lmesnik Please integrate @fguallini 's suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2044920811

From lmesnik at openjdk.org  Tue Apr 15 16:06:08 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Apr 2025 16:06:08 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v9]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <jhPjQ2eoKmeFgPRUVcYDEsdbTUNJBnjwSFeEXKP3ByI=.d4e2fde1-c6c2-4196-9ff6-805305e3162e@github.com>

> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
> 
> For first case
> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
> 
> For 2nd case 
> The library classes are compiled using @build tag and library classes are placed into some shared location.
> 
> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
> 
> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
> 
> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
> test1/Test.java
> test2/Test.java
> with both tests having
> 
> @library "/"
> @build Test
> 
> we are going just to have one Test class in library directory.
> 
> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
> 
> Times for tier1 execution with fix:
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
> 
> and before fix
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
> 
> The full fix might require more testing and adding testcase.
> Please note that there are plans to work on the 
> https://bugs.openjdk.org/browse/CODETOOLS-7903882
> and
> https://bugs.openjdk.org/browse/JDK-8346058
> So ...

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/d0b28bff..997c061e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=08
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/256/head:pull/256

PR: https://git.openjdk.org/jtreg/pull/256

From lmesnik at openjdk.org  Tue Apr 15 16:06:09 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Apr 2025 16:06:09 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v4]
In-Reply-To: <iCJ6Ie-_8qe4aKZtiUfvXt78VHbRFe7_jMhKfhVYcQI=.b0663fcd-6aa1-45f1-9850-a33bbbfc24c5@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>
 <7ZO4k9XFluGH13LtXgXbRtZ2oRPonPhFA0BYmTqRO9g=.3996fe32-445c-49b2-9f56-ef31754490ae@github.com>
 <iCJ6Ie-_8qe4aKZtiUfvXt78VHbRFe7_jMhKfhVYcQI=.b0663fcd-6aa1-45f1-9850-a33bbbfc24c5@github.com>
Message-ID: <Pf8Q3-EaHR0KHQAI-n-tUj_8pdSHxFmV48qMz_vmIFo=.84afdda3-9cd1-4746-b641-e0ffaf249c3f@github.com>

On Tue, 15 Apr 2025 15:32:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/share/doc/javatest/regtest/tag-spec.html line 261:
>> 
>>> 259: A test that relies upon library classes might contain appropriate
>>> 260: <code>@build</code> directives to explictily point classes to be compiled.
>>> 261: This might be useful when test depends on linbrary classes during runtime only.
>> 
>> Suggestion:
>> 
>> This might be useful when test depends on library classes during runtime only.
>
> @lmesnik Please integrate @fguallini 's suggestion.

Done, just missed first time,

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2044982844

From jvernee at openjdk.org  Wed Apr 16 13:29:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 16 Apr 2025 13:29:56 GMT
Subject: RFR: 7903988: IDEA plugin: temp directories don't work on Windows
 [v2]
In-Reply-To: <nGELtc5c4A04A56IXjj58dCe6DoGrnTNGrWDiMea67E=.5b03ed2b-068f-47d8-839a-5a89d2885837@github.com>
References: <nGELtc5c4A04A56IXjj58dCe6DoGrnTNGrWDiMea67E=.5b03ed2b-068f-47d8-839a-5a89d2885837@github.com>
Message-ID: <sI5thYRlzigF9Moa8lZbm855snwIRibI40h5kLCa1m0=.fc7176b7-a9e5-4295-9eed-cc9e0a188b7b@github.com>

> Copied from the JBS issue:
> 
> To find the temporary directory on Windows, one of the environment variables `TMP`, `TEMP`, or `USERPROFILE` is needed [1](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha#remarks). If these are not set, `C:\WINDOWS` is used as a fallback, but this directory is typically inaccessible (and generally not really a directory you want to leave temp files in).
> 
> The IDEA plugin currently doesn't forward these variables to the jtreg process that it starts, resulting in them being unset. For tests that e.g. create temporary files or directories, this result in an `AccessDeniedException` such as:
> 
> 
> java.nio.file.AccessDeniedException: C:\\WINDOWS\\asdf12599356154200781179
>   at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
>   at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
>   at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
>   at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:231)
>   at java.base/java.nio.file.Files.newByteChannel(Files.java:357)
>   at java.base/java.nio.file.Files.createFile(Files.java:609)
>   at java.base/java.nio.file.TempFileHelper.create(TempFileHelper.java:132)
>   at java.base/java.nio.file.TempFileHelper.createTempFile(TempFileHelper.java:150)
>   at java.base/java.nio.file.Files.createTempFile(Files.java:842)
>   at TestTempDir.testTempDir(TestTempDir.java:39)
> 
> 
> The plugin should forward these environment variables on Windows, to make sure that the temporary directory can be found by tests.
> 
> Tested locally with a simple test that calls [`Files::createTempFile`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...)), and checked that these changes prevent an `AccessDeniedError` from being thrown.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into WindowsTempVars
 - Reorder imports
 - review comments
 - reduce diff
 - Forward TMP TEMP and USERPROFILE to forked process on Windows

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/258/files
  - new: https://git.openjdk.org/jtreg/pull/258/files/551455c3..8b665eb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=258&range=01
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=258&range=00-01

  Stats: 168 lines in 51 files changed: 8 ins; 1 del; 159 mod
  Patch: https://git.openjdk.org/jtreg/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/258/head:pull/258

PR: https://git.openjdk.org/jtreg/pull/258

From jvernee at openjdk.org  Wed Apr 16 13:29:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 16 Apr 2025 13:29:56 GMT
Subject: RFR: 7903988: IDEA plugin: temp directories don't work on Windows
 [v2]
In-Reply-To: <MnqRn6RQn2sGikfvFLnflVd_Hp1BBZh2a0Qi4eqQE9g=.4396b1ad-0781-4fe7-91c5-5747d5d4f1bd@github.com>
References: <nGELtc5c4A04A56IXjj58dCe6DoGrnTNGrWDiMea67E=.5b03ed2b-068f-47d8-839a-5a89d2885837@github.com>
 <u_zD3ohZF2keDtGDji5CVi-3kyTcLxWFDK_Rl5i84hA=.ff8e622d-7a9f-4317-aaa1-cd75a0543e53@github.com>
 <MnqRn6RQn2sGikfvFLnflVd_Hp1BBZh2a0Qi4eqQE9g=.4396b1ad-0781-4fe7-91c5-5747d5d4f1bd@github.com>
Message-ID: <kfnZX1m5olHtxDNwDFatmdG9DR8Hn7YxUUUFTyo2EGo=.0a18d399-e4a2-4c47-a660-dc7a01ea75d3@github.com>

On Mon, 14 Apr 2025 18:00:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/JTRegConfigurationRunnableState.java line 111:
>> 
>>> 109:         javaParameters.setMainClass("com.sun.javatest.regtest.Main");
>>> 110: 
>>> 111:         if (JTRegUtils.IS_WINDOWS) {
>> 
>> What happens if `System.getenv("TMP")` returns `null`?
>> 
>> Wouldn't it be better to check that first for each pair, and if the value is non-null, add the pair to the  `javaParameters` instance?
>
> That's probably better yeah. I was assuming the value would just be ignored if null. The implementation of `addEnv` just adds the value to a map.

I've changed it to only conditionally forward variables that are not null.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/258#discussion_r2046936273

From rriggs at openjdk.org  Wed Apr 16 14:19:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Apr 2025 14:19:55 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v9]
In-Reply-To: <jhPjQ2eoKmeFgPRUVcYDEsdbTUNJBnjwSFeEXKP3ByI=.d4e2fde1-c6c2-4196-9ff6-805305e3162e@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <jhPjQ2eoKmeFgPRUVcYDEsdbTUNJBnjwSFeEXKP3ByI=.d4e2fde1-c6c2-4196-9ff6-805305e3162e@github.com>
Message-ID: <KZ7WeAEDU0HRXD_4KMWeWSfkIFtlHYOQDHX-JwvtsiY=.2280f54d-c870-421a-b259-c908d5b04a68@github.com>

On Tue, 15 Apr 2025 16:06:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
>> 
>> For first case
>> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
>> 
>> For 2nd case 
>> The library classes are compiled using @build tag and library classes are placed into some shared location.
>> 
>> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
>> 
>> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
>> 
>> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
>> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
>> test1/Test.java
>> test2/Test.java
>> with both tests having
>> 
>> @library "/"
>> @build Test
>> 
>> we are going just to have one Test class in library directory.
>> 
>> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
>> 
>> Times for tier1 execution with fix:
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
>> 
>> and before fix
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
>> 
>> The full fix might require more testing and adding testcase.
>> Please note that there are plans to work on the 
>> https://bugs.openjd...
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo

Changes requested by rriggs (no project role).

src/share/doc/javatest/regtest/tag-spec.html line 256:

> 254: 
> 255: <p>In general, classes in library directories are not automatically compiled
> 256: as part of a compilation command explicitly naming the source files containing

Where is the "shareLibraries" property defined? I'm expecting to see it defined in the TEST.ROOT or TEST.properties table like "enablePreview", etc.

Also, I think it should not be plural. It applies to this particular library.

Maybe I misunderstand.

src/share/doc/javatest/regtest/tag-spec.html line 261:

> 259: A test that relies upon library classes might contain appropriate
> 260: <code>@build</code> directives to explictily point classes to be compiled.
> 261: This might be useful when test depends on library classes during runtime only.

Suggestion:

those classes. The library directory is used as an additional sourcepath for test compilation.
So jtreg implicitly compiles all test dependencies that are located in a library directory.
A test that relies upon library classes might contain appropriate
<code>@build</code> directives to explicitly compile classes.
This might be useful when a test depends on library classes during runtime only.

-------------

PR Review: https://git.openjdk.org/jtreg/pull/256#pullrequestreview-2772661934
PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2047042748
PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2047015200

From jvernee at openjdk.org  Wed Apr 16 14:50:35 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 16 Apr 2025 14:50:35 GMT
Subject: RFR: 7903988: IDEA plugin: temp directories don't work on Windows
 [v3]
In-Reply-To: <nGELtc5c4A04A56IXjj58dCe6DoGrnTNGrWDiMea67E=.5b03ed2b-068f-47d8-839a-5a89d2885837@github.com>
References: <nGELtc5c4A04A56IXjj58dCe6DoGrnTNGrWDiMea67E=.5b03ed2b-068f-47d8-839a-5a89d2885837@github.com>
Message-ID: <YXWiQY4eJbcZCC6PbUqoEvAFOkERxGNNtMYQvmv91mo=.1c61eb67-8ae4-45a0-8c6d-a60731c5d2a4@github.com>

> Copied from the JBS issue:
> 
> To find the temporary directory on Windows, one of the environment variables `TMP`, `TEMP`, or `USERPROFILE` is needed [1](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha#remarks). If these are not set, `C:\WINDOWS` is used as a fallback, but this directory is typically inaccessible (and generally not really a directory you want to leave temp files in).
> 
> The IDEA plugin currently doesn't forward these variables to the jtreg process that it starts, resulting in them being unset. For tests that e.g. create temporary files or directories, this result in an `AccessDeniedException` such as:
> 
> 
> java.nio.file.AccessDeniedException: C:\\WINDOWS\\asdf12599356154200781179
>   at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
>   at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
>   at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
>   at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:231)
>   at java.base/java.nio.file.Files.newByteChannel(Files.java:357)
>   at java.base/java.nio.file.Files.createFile(Files.java:609)
>   at java.base/java.nio.file.TempFileHelper.create(TempFileHelper.java:132)
>   at java.base/java.nio.file.TempFileHelper.createTempFile(TempFileHelper.java:150)
>   at java.base/java.nio.file.Files.createTempFile(Files.java:842)
>   at TestTempDir.testTempDir(TestTempDir.java:39)
> 
> 
> The plugin should forward these environment variables on Windows, to make sure that the temporary directory can be found by tests.
> 
> Tested locally with a simple test that calls [`Files::createTempFile`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...)), and checked that these changes prevent an `AccessDeniedError` from being thrown.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/258/files
  - new: https://git.openjdk.org/jtreg/pull/258/files/8b665eb0..697a8b8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=258&range=02
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=258&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jtreg/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/258/head:pull/258

PR: https://git.openjdk.org/jtreg/pull/258

From lmesnik at openjdk.org  Wed Apr 16 20:41:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Apr 2025 20:41:44 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v10]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <3-6C9Bc4DxvTUCrIYFQgV03FwB8Tb-lcr5jEmUJe6Ec=.9ba9f802-21f8-4f82-9abd-58739ef7d836@github.com>

> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
> 
> For first case
> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
> 
> For 2nd case 
> The library classes are compiled using @build tag and library classes are placed into some shared location.
> 
> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
> 
> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
> 
> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
> test1/Test.java
> test2/Test.java
> with both tests having
> 
> @library "/"
> @build Test
> 
> we are going just to have one Test class in library directory.
> 
> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
> 
> Times for tier1 execution with fix:
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
> 
> and before fix
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
> 
> The full fix might require more testing and adding testcase.
> Please note that there are plans to work on the 
> https://bugs.openjdk.org/browse/CODETOOLS-7903882
> and
> https://bugs.openjdk.org/browse/JDK-8346058
> So ...

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Update src/share/doc/javatest/regtest/tag-spec.html
  
  Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/997c061e..9dfaf822

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=09
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=08-09

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jtreg/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/256/head:pull/256

PR: https://git.openjdk.org/jtreg/pull/256

From lmesnik at openjdk.org  Wed Apr 16 20:45:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Apr 2025 20:45:54 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v9]
In-Reply-To: <KZ7WeAEDU0HRXD_4KMWeWSfkIFtlHYOQDHX-JwvtsiY=.2280f54d-c870-421a-b259-c908d5b04a68@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <jhPjQ2eoKmeFgPRUVcYDEsdbTUNJBnjwSFeEXKP3ByI=.d4e2fde1-c6c2-4196-9ff6-805305e3162e@github.com>
 <KZ7WeAEDU0HRXD_4KMWeWSfkIFtlHYOQDHX-JwvtsiY=.2280f54d-c870-421a-b259-c908d5b04a68@github.com>
Message-ID: <6AkpTDN0UhcLF7edVQVjC-B4p_YOzGfew0ekw5_VjIE=.15a91e76-c299-44c8-afeb-2eee36c0d8f6@github.com>

On Wed, 16 Apr 2025 14:17:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo
>
> src/share/doc/javatest/regtest/tag-spec.html line 256:
> 
>> 254: 
>> 255: <p>In general, classes in library directories are not automatically compiled
>> 256: as part of a compilation command explicitly naming the source files containing
> 
> Where is the "shareLibraries" property defined? I'm expecting to see it defined in the TEST.ROOT or TEST.properties table like "enablePreview", etc.
> 
> Also, I think it should not be plural. It applies to this particular library.
> 
> Maybe I misunderstand.

The flags should  be located in TEST.ROOT or TEST.properties for all libraries that are used by tests. It is not specific for any particular library. 

This flag is requested by @sormuras  to restore original behavior if something goes wrong with new mode.

I would like to keep temporary for a couple of releases and remove if it is not needed.  I don't like to maintain different execution modes if it is not needed.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2047719837

From lmesnik at openjdk.org  Wed Apr 16 20:54:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Apr 2025 20:54:39 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v11]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <bFdRQ5XiNuZE0pfYHIQYiU7YzyAT6Mwp1GsnB7MZ994=.d401d10f-deeb-4d18-9795-067e8b662cfe@github.com>

> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
> 
> For first case
> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
> 
> For 2nd case 
> The library classes are compiled using @build tag and library classes are placed into some shared location.
> 
> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
> 
> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
> 
> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
> test1/Test.java
> test2/Test.java
> with both tests having
> 
> @library "/"
> @build Test
> 
> we are going just to have one Test class in library directory.
> 
> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
> 
> Times for tier1 execution with fix:
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
> 
> and before fix
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
> 
> The full fix might require more testing and adding testcase.
> Please note that there are plans to work on the 
> https://bugs.openjdk.org/browse/CODETOOLS-7903882
> and
> https://bugs.openjdk.org/browse/JDK-8346058
> So ...

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '7902847' of https://github.com/lmesnik/jtreg into 7902847
 - fixed spec

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/9dfaf822..271d58b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=10
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/256/head:pull/256

PR: https://git.openjdk.org/jtreg/pull/256

From jvernee at openjdk.org  Thu Apr 17 12:22:04 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 17 Apr 2025 12:22:04 GMT
Subject: RFR: 7903990: IDEA plugin: Itemize junit test results
Message-ID: <ZI89pJTXDDj0EFrBqdUhPxTX_kjxVGeJ-efuQtMM9dw=.37370ec2-3c25-455a-b0e9-2f4b3a0a51ad@github.com>

Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example:

![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d)

Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: 

1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. 
2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events.

Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff.

-------------

Commit messages:
 - bump copyright years
 - polish
 - add duration to junit tests
 - improve code organization
 - Use Section api
 - polish
 - make parsing more robust
 - Make parsing jtr file safer
 - Use custom test locator
 - WIP - Itemized Results: sections
 - ... and 1 more: https://git.openjdk.org/jtreg/compare/19cdb840...d92de904

Changes: https://git.openjdk.org/jtreg/pull/260/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=260&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903990
  Stats: 396 lines in 4 files changed: 340 ins; 20 del; 36 mod
  Patch: https://git.openjdk.org/jtreg/pull/260.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/260/head:pull/260

PR: https://git.openjdk.org/jtreg/pull/260

From rriggs at openjdk.org  Thu Apr 17 18:59:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 18:59:12 GMT
Subject: RFR: 7903981: Support easy way to use current class name for test
 actions [v6]
In-Reply-To: <bOT_JvqbdQqzNOGQqbd14_BFshrD6K04wJKbbJr3q5c=.65620549-2e0b-43cd-823f-2e78e5564c03@github.com>
References: <xKBXDO87QtMLjZYQSFoQTV_cYsb-kT0YeOH7y0oXRx8=.9a11d204-265d-4e03-aa18-6aa914c4de6d@github.com>
 <bOT_JvqbdQqzNOGQqbd14_BFshrD6K04wJKbbJr3q5c=.65620549-2e0b-43cd-823f-2e78e5564c03@github.com>
Message-ID: <QSy_9OlFkA5zPp2N-L_kyXsUqTgBScQzOO9MfNQ_oAI=.1b2f512d-45cd-46c2-bcb6-5f1f0a4ff4c4@github.com>

On Mon, 14 Apr 2025 13:13:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to allow an easier way to use current class name for test actions.
>> 
>> Test authors usually specify the name of a test class to be run by `jtreg` 1:1 in a `@run` action directive. This PR introduces the new test property `test.main.class` and tries to initialize it with the fully-qualified class name of the test class. It is composed of the package name and the truncated file name of `.java` source file passed to `jtreg`: `SomeTest.java` becomes `SomeTest`
>> 
>> Example for `Test.java` in the unnamed package:
>> - `@run main Test` - `@run main ${test.main.class}`
>> 
>> Example for `Test.java` declaring `package p;`:
>> - `@run main p.Test` - `@run main ${test.main.class}`
>> 
>> See also: [CODETOOLS-7902352: Support use of ${property.name} in action args](https://bugs.openjdk.org/browse/CODETOOLS-7902352)
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical expression for expecting non-zero result

Looks ok to me, (Not a Jtreg Reviewer)

-------------

Marked as reviewed by rriggs (no project role).

PR Review: https://git.openjdk.org/jtreg/pull/257#pullrequestreview-2776656964

From rriggs at openjdk.org  Thu Apr 17 21:41:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 21:41:11 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v9]
In-Reply-To: <6AkpTDN0UhcLF7edVQVjC-B4p_YOzGfew0ekw5_VjIE=.15a91e76-c299-44c8-afeb-2eee36c0d8f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <jhPjQ2eoKmeFgPRUVcYDEsdbTUNJBnjwSFeEXKP3ByI=.d4e2fde1-c6c2-4196-9ff6-805305e3162e@github.com>
 <KZ7WeAEDU0HRXD_4KMWeWSfkIFtlHYOQDHX-JwvtsiY=.2280f54d-c870-421a-b259-c908d5b04a68@github.com>
 <6AkpTDN0UhcLF7edVQVjC-B4p_YOzGfew0ekw5_VjIE=.15a91e76-c299-44c8-afeb-2eee36c0d8f6@github.com>
Message-ID: <tOmIDzh67-pU6ijGZH-Q54_xJ9ExSPKkEEftbxV0ICU=.1bd96a61-f292-454a-8e90-1858cf13d62a@github.com>

On Wed, 16 Apr 2025 20:42:54 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/share/doc/javatest/regtest/tag-spec.html line 256:
>> 
>>> 254: 
>>> 255: <p>In general, classes in library directories are not automatically compiled
>>> 256: as part of a compilation command explicitly naming the source files containing
>> 
>> Where is the "shareLibraries" property defined? I'm expecting to see it defined in the TEST.ROOT or TEST.properties table like "enablePreview", etc.
>> 
>> Also, I think it should not be plural. It applies to this particular library.
>> 
>> Maybe I misunderstand.
>
> The flags should  be located in TEST.ROOT or TEST.properties for all libraries that are used by tests. It is not specific for any particular library. 
> 
> This flag is requested by @sormuras  to restore original behavior if something goes wrong with new mode.
> 
> I would like to keep temporary for a couple of releases and remove if it is not needed.  I don't like to maintain different execution modes if it is not needed.

I was expecting this text in the tag-spec to describe both behavior(s) controlled by `shareLibraries`.
And mention the property and clearly define the behavior of each case. 

That does not seem to be intended.  Instead only the changed behavior is documented and the property will not be documented. I understood the feature to control the destination directory for compiled classes but from this description it controls the source path, not the destination.

Since the behavior is being changed somewhat incompatibly, the text should clearly describe the new behavior and call out the differences and how to get the previous behavior if needed.

It would be clearer the property and its behaviors were documented in `Locations.getLibLcn` .
The name of the property should more clearly indicate it is for compatibility and the behavior when it is set.

The words "might" and "may" are red flags in any specification.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2049683639

From jvernee at openjdk.org  Thu Apr 17 21:50:51 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 17 Apr 2025 21:50:51 GMT
Subject: RFR: 7903990: IDEA plugin: Itemize junit test results
In-Reply-To: <ZI89pJTXDDj0EFrBqdUhPxTX_kjxVGeJ-efuQtMM9dw=.37370ec2-3c25-455a-b0e9-2f4b3a0a51ad@github.com>
References: <ZI89pJTXDDj0EFrBqdUhPxTX_kjxVGeJ-efuQtMM9dw=.37370ec2-3c25-455a-b0e9-2f4b3a0a51ad@github.com>
Message-ID: <BfagwVE8ZUtnttN04VeL2DUagH8YHO-tw8mb5PWDtOU=.28b5bb8d-62ef-4122-a172-9262e4ff9d3f@github.com>

On Tue, 15 Apr 2025 20:48:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example:
> 
> ![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d)
> 
> Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: 
> 
> 1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. 
> 2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events.
> 
> Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff.

Another caveat of this feature I've run into, or rather, what seems to be a limitation imposed by IntelliJ: in order to show the right-click dialogue to re-run a test case, we need to look up the location of the test class/method, which then gets passed back to the plugin later to create the run configuration. This involves at least looking up a class using IntelliJ's builtin lookup functionality.

The issue is: when we look up the name of the test class, the file it is in needs to be in an active IntelliJ test source root. The plugin will normally automatically set up the test source root when opening a test file, but if you forget to do this before running the test, the test class can not be found, and instead of the dialogue from the screen shot, a dialogue with the text 'Nothing here' will be shown instead.

![image](https://github.com/user-attachments/assets/5f3afc37-fcb6-4d3b-9776-4eb4e86e2c51)

The worse thing is that this lookup result seems to be cached inside the IDE, so even if you add the test source root after the seeing this, the IDE will keep showing the 'Nothing here' dialogue. The only way I've found to resolve that issue is to restart the IDE.

In other words: it is important to make sure the test you're running are in an active test source root _before_ running the tests.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/260#issuecomment-2814083451

From lmesnik at openjdk.org  Thu Apr 17 22:12:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 17 Apr 2025 22:12:53 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v9]
In-Reply-To: <tOmIDzh67-pU6ijGZH-Q54_xJ9ExSPKkEEftbxV0ICU=.1bd96a61-f292-454a-8e90-1858cf13d62a@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <jhPjQ2eoKmeFgPRUVcYDEsdbTUNJBnjwSFeEXKP3ByI=.d4e2fde1-c6c2-4196-9ff6-805305e3162e@github.com>
 <KZ7WeAEDU0HRXD_4KMWeWSfkIFtlHYOQDHX-JwvtsiY=.2280f54d-c870-421a-b259-c908d5b04a68@github.com>
 <6AkpTDN0UhcLF7edVQVjC-B4p_YOzGfew0ekw5_VjIE=.15a91e76-c299-44c8-afeb-2eee36c0d8f6@github.com>
 <tOmIDzh67-pU6ijGZH-Q54_xJ9ExSPKkEEftbxV0ICU=.1bd96a61-f292-454a-8e90-1858cf13d62a@github.com>
Message-ID: <cUGUYxMO-SMyakA_FL2lhk7ngDSp9FmSAxZmSIZIoZ4=.449e5b1d-a90c-4074-8f20-30c4811acecb@github.com>

On Thu, 17 Apr 2025 21:38:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The flags should  be located in TEST.ROOT or TEST.properties for all libraries that are used by tests. It is not specific for any particular library. 
>> 
>> This flag is requested by @sormuras  to restore original behavior if something goes wrong with new mode.
>> 
>> I would like to keep temporary for a couple of releases and remove if it is not needed.  I don't like to maintain different execution modes if it is not needed.
>
> I was expecting this text in the tag-spec to describe both behavior(s) controlled by `shareLibraries`.
> And mention the property and clearly define the behavior of each case. 
> 
> That does not seem to be intended.  Instead only the changed behavior is documented and the property will not be documented. I understood the feature to control the destination directory for compiled classes but from this description it controls the source path, not the destination.
> 
> Since the behavior is being changed somewhat incompatibly, the text should clearly describe the new behavior and call out the differences and how to get the previous behavior if needed.
> 
> It would be clearer the property and its behaviors were documented in `Locations.getLibLcn` .
> The name of the property should more clearly indicate it is for compatibility and the behavior when it is set.
> 
> The words "might" and "may" are red flags in any specification.

The property controls only to where compile put compiled classes for `@build` tag. There are no changes related to source paths.  It remains completely the same and change shouldn't break any test.

The `might` in this part

A test that relies upon library classes might contain appropriate
<code>@build</code> directives to explicitly compile classes.
This might be useful when a test depends on library classes during runtime only.

just describes when `@build` tag still is useful useful. It might be not evident that testlibrary classes are not compiled if javac can't understand that they are used. 
Also, redundant `@build` is not an error, but not useful at all. 

Does it looks better?


A test that relies upon library classes that  are not implicitly resolved by during compilation should have appropriate
<code>@build</code> directives to explicitly compile required classes.
This is required when a test depends on library classes during runtime only.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2049707247

From rriggs at openjdk.org  Thu Apr 17 22:51:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 22:51:53 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v9]
In-Reply-To: <cUGUYxMO-SMyakA_FL2lhk7ngDSp9FmSAxZmSIZIoZ4=.449e5b1d-a90c-4074-8f20-30c4811acecb@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <jhPjQ2eoKmeFgPRUVcYDEsdbTUNJBnjwSFeEXKP3ByI=.d4e2fde1-c6c2-4196-9ff6-805305e3162e@github.com>
 <KZ7WeAEDU0HRXD_4KMWeWSfkIFtlHYOQDHX-JwvtsiY=.2280f54d-c870-421a-b259-c908d5b04a68@github.com>
 <6AkpTDN0UhcLF7edVQVjC-B4p_YOzGfew0ekw5_VjIE=.15a91e76-c299-44c8-afeb-2eee36c0d8f6@github.com>
 <tOmIDzh67-pU6ijGZH-Q54_xJ9ExSPKkEEftbxV0ICU=.1bd96a61-f292-454a-8e90-1858cf13d62a@github.com>
 <cUGUYxMO-SMyakA_FL2lhk7ngDSp9FmSAxZmSIZIoZ4=.449e5b1d-a90c-4074-8f20-30c4811acecb@github.com>
Message-ID: <t6kdJ-O8--uTx5aWt9_Ji5TL_Dail9YqEjljpaVmh9E=.9358d43f-a06a-4ef0-a493-97cd56d78fbf@github.com>

On Thu, 17 Apr 2025 22:10:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> I was expecting this text in the tag-spec to describe both behavior(s) controlled by `shareLibraries`.
>> And mention the property and clearly define the behavior of each case. 
>> 
>> That does not seem to be intended.  Instead only the changed behavior is documented and the property will not be documented. I understood the feature to control the destination directory for compiled classes but from this description it controls the source path, not the destination.
>> 
>> Since the behavior is being changed somewhat incompatibly, the text should clearly describe the new behavior and call out the differences and how to get the previous behavior if needed.
>> 
>> It would be clearer the property and its behaviors were documented in `Locations.getLibLcn` .
>> The name of the property should more clearly indicate it is for compatibility and the behavior when it is set.
>> 
>> The words "might" and "may" are red flags in any specification.
>
> The property controls only to where compile put compiled classes for `@build` tag. There are no changes related to source paths.  It remains completely the same and change shouldn't break any test.
> 
> The `might` in this part
> 
> A test that relies upon library classes might contain appropriate
> <code>@build</code> directives to explicitly compile classes.
> This might be useful when a test depends on library classes during runtime only.
> 
> just describes when `@build` tag still is useful useful. It might be not evident that testlibrary classes are not compiled if javac can't understand that they are used. 
> Also, redundant `@build` is not an error, but not useful at all. 
> 
> Does it looks better?
> 
> 
> A test that relies upon library classes that  are not implicitly resolved by during compilation should have appropriate
> <code>@build</code> directives to explicitly compile required classes.
> This is required when a test depends on library classes during runtime only.

The only text below that described a change mentions "sourcepath" and does not mention the directories the files are compiled into.

I'm not sure what is being described below except to dispel the idea that @build is necessary.

I don't have better words at the moment but would probably mention classes that were referenced using Reflection or explicitly loaded.  But being direct about when @build is necessary will be clearer.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2049730815

From lmesnik at openjdk.org  Fri Apr 18 01:28:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 18 Apr 2025 01:28:01 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v9]
In-Reply-To: <t6kdJ-O8--uTx5aWt9_Ji5TL_Dail9YqEjljpaVmh9E=.9358d43f-a06a-4ef0-a493-97cd56d78fbf@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <jhPjQ2eoKmeFgPRUVcYDEsdbTUNJBnjwSFeEXKP3ByI=.d4e2fde1-c6c2-4196-9ff6-805305e3162e@github.com>
 <KZ7WeAEDU0HRXD_4KMWeWSfkIFtlHYOQDHX-JwvtsiY=.2280f54d-c870-421a-b259-c908d5b04a68@github.com>
 <6AkpTDN0UhcLF7edVQVjC-B4p_YOzGfew0ekw5_VjIE=.15a91e76-c299-44c8-afeb-2eee36c0d8f6@github.com>
 <tOmIDzh67-pU6ijGZH-Q54_xJ9ExSPKkEEftbxV0ICU=.1bd96a61-f292-454a-8e90-1858cf13d62a@github.com>
 <cUGUYxMO-SMyakA_FL2lhk7ngDSp9FmSAxZmSIZIoZ4=.449e5b1d-a90c-4074-8f20-30c4811acecb@github.com>
 <t6kdJ-O8--uTx5aWt9_Ji5TL_Dail9YqEjljpaVmh9E=.9358d43f-a06a-4ef0-a493-97cd56d78fbf@github.com>
Message-ID: <yMjZS0nnpUSQxRwMoy51mmKnpGv-sj2SYwIPz88AlJM=.b890eaa5-d9b0-4751-8ef6-62e3079875b4@github.com>

On Thu, 17 Apr 2025 22:48:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The property controls only to where compile put compiled classes for `@build` tag. There are no changes related to source paths.  It remains completely the same and change shouldn't break any test.
>> 
>> The `might` in this part
>> 
>> A test that relies upon library classes might contain appropriate
>> <code>@build</code> directives to explicitly compile classes.
>> This might be useful when a test depends on library classes during runtime only.
>> 
>> just describes when `@build` tag still is useful useful. It might be not evident that testlibrary classes are not compiled if javac can't understand that they are used. 
>> Also, redundant `@build` is not an error, but not useful at all. 
>> 
>> Does it looks better?
>> 
>> 
>> A test that relies upon library classes that  are not implicitly resolved by during compilation should have appropriate
>> <code>@build</code> directives to explicitly compile required classes.
>> This is required when a test depends on library classes during runtime only.
>
> The only text below that described a change mentions "sourcepath" and does not mention the directories the files are compiled into.
> 
> I'm not sure what is being described below except to dispel the idea that @build is necessary.
> 
> I don't have better words at the moment but would probably mention classes that were referenced using Reflection or explicitly loaded.  But being direct about when @build is necessary will be clearer.

I see, the changes in this sentence are done just to more confident describe how the compilation with implicit library works. The actual behavior is not changed. 
The library is used as a sourcepath for javac allowing it to pick and compile classes required to compile test source code or build/compiles instructions.
It works exactly as described in the:
https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#additional-source-files
So I just mention how exactly commands are mapped to javac command.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2049815058

From lmesnik at openjdk.org  Fri Apr 18 02:21:23 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 18 Apr 2025 02:21:23 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v12]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <bqUbaO7aRhzrLaXx_EXcL_SkBaJA9s_KcSqGlesdXjs=.8937b67c-3be0-41a3-837b-ea0b0ba91e1c@github.com>

> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
> 
> For first case
> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
> 
> For 2nd case 
> The library classes are compiled using @build tag and library classes are placed into some shared location.
> 
> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
> 
> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
> 
> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
> test1/Test.java
> test2/Test.java
> with both tests having
> 
> @library "/"
> @build Test
> 
> we are going just to have one Test class in library directory.
> 
> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
> 
> Times for tier1 execution with fix:
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
> 
> and before fix
> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
> 
> The full fix might require more testing and adding testcase.
> Please note that there are plans to work on the 
> https://bugs.openjdk.org/browse/CODETOOLS-7903882
> and
> https://bugs.openjdk.org/browse/JDK-8346058
> So ...

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fx

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/271d58b3..34372797

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=11
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/256/head:pull/256

PR: https://git.openjdk.org/jtreg/pull/256