From duke at openjdk.org  Thu Jan  2 10:14:58 2025
From: duke at openjdk.org (andrlos)
Date: Thu, 2 Jan 2025 10:14:58 GMT
Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash
 testing
In-Reply-To: <ts-j8xJf1nIuxc7TPq43byL3C3qOKc4NA3SqrhUPasY=.0b915b11-4660-49ce-bd58-33d16a3d3efa@github.com>
References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
 <uA9y4ZKCN_-Rsri91_WEPdahbaZOPe6W-fn5YzhP7QA=.d1764c3f-eab1-4689-b0e5-22d0ead28a18@github.com>
 <8Vqx8LlIfN9WFhOFOpF7v1dAul4balD5EdGktzip9hA=.f6a673f6-0089-41ec-8241-8cc5f01bcfb5@github.com>
 <ts-j8xJf1nIuxc7TPq43byL3C3qOKc4NA3SqrhUPasY=.0b915b11-4660-49ce-bd58-33d16a3d3efa@github.com>
Message-ID: <QEDVqT0IMChBOfiuWPCwgf8E69OwP3QUFtqSlNipdyQ=.724afd28-3df8-46dc-854a-da5f38dfdb3f@github.com>

On Tue, 12 Nov 2024 09:39:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @sormuras 	feast your eyes on the code below :D
>> 
>> 
>> public class CrashOnlyStatusTransformer implements StatusTransformer {
>>         @Override
>>         public Status transform(Status originalStatus, TestDescription td) {
>>             Status newStatus = originalStatus;
>>             if(originalStatus.getType() == Status.FAILED && ! this.didCrash(td)){
>>                 newStatus = new Status(Status.PASSED, "Just a regular failure.");
>>             }
>>             return newStatus;
>>         }
>> 
>>         private boolean didCrash(TestDescription td){
>>             Pattern pattern = Pattern.compile("^hs_err_pid(\\d+)\.log");
>>             List<String> hs_errs = Arrays.stream(td.getDir().list()).filter(pattern.asPredicate()).collect(Collectors.toList());
>>             return !hs_errs.isEmpty();
>>     }
>> }
>> 
>> 
>> this is an approach that we use for crashtesting with debug jdk builds to separate crashes from regular failures
>
> Hello @andrlos, looking at that code you pasted:
> 
> if(originalStatus.getType() == Status.FAILED && ! this.didCrash(td)){
>     newStatus = new Status(Status.PASSED, "Just a regular failure.");
> }
> 
> It looks odd to be marking a failed test as successful. Furthermore, doesn't a crashed JVM result in test status to be `Status.ERROR`?

@jaikiran @sormuras WDYT?

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

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

From maurizio.cimadamore at oracle.com  Tue Jan  7 17:24:06 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 7 Jan 2025 17:24:06 +0000
Subject: RFC: jtreg IntelliJ plugin: run individual test methods
In-Reply-To: <1aba836c-cc85-4323-abba-ee8a674aaac5@oracle.com>
References: <1aba836c-cc85-4323-abba-ee8a674aaac5@oracle.com>
Message-ID: <c005c6d6-b0b2-4d53-9449-72bce1dc503b@oracle.com>

Hi Jorn,
your extension to the plugin seems a fine idea - it would be nice to be 
able to run specific methods through the plugin.

IMHO, adding parameter types might be a step too far - the general 
problem of "predicting" which binary name a source class name might have 
is rather hard, and it amounts at heuristics (e.g. there's more to it 
than just replacing dots with dollars, as you also take into account as 
to whether other class declared with a dollar in their name (!!) are 
present).

I wonder if a sensible first step would be to just support the same 
logic that jtreg runners also support -- e.g. just a method name. After 
all, it is extremely unlikely to have overloaded test methods. E.g. it 
seems to me that we're in a case where we can get almost all the benefit 
at a fraction of the complexity.

What do you think?

Maurizio

On 07/01/2025 17:05, Jorn Vernee wrote:
> Hello,
>
> Jtreg has for a while now had the ability to attach a query string to 
> the name of a test, which then gets used by the JUnit or TestNG runner 
> to select a particular test method to run.
>
> The intellij plugin currently doesn't have support for specifying a 
> query string, or running individual test methods, so I've put together 
> a patch that adds that support [1]. This support has two parts: add a 
> 'Query String' field to the jtreg test configuration window in 
> intellij, and automatically populate the query string when creating a 
> test configuration from a test method in a source file.
>
> Most of this is pretty straightforward. I did run into a small issue: 
> when a method takes parameters, junit requires the parameter types the 
> be specified as binary names. It takes some work to derive the binary 
> name of the parameter types from the source AST representation exposed 
> by intellij to the plugin.
>
> Additionally, I had to amend the format of the query strings accepted 
> by the TestNG and JUnit runners to accept a trailing list of parameter 
> type names. The new format of the query string is:
>
> <methodName>[-<parameterTypeName>[...,<parameterTypeName>]]
>
> Does this?seem like a good approach?
>
> Future enhancements could include:
>
> 1.) displaying individual test methods as results in the intellij UI. 
> The problem with doing this is currently that jtreg does not forward 
> the results from JUnit/TestNG to the observer the plugin attaches to 
> jtreg. Adding support for this seems straightforward enough. 
> Potentially it would also be useful to 'itemize' other steps that a 
> jtreg test takes, such as compiling, or individual @run tags.
> 2.) for parameterized tests, the TestNG runner that comes with 
> intellij shows each case?(i.e. combination of paramters) individually 
> as a result in the UI, and allows re-running just a single case 
> through a unique ID. I think JUnit has similar support for this. We 
> could add a similar feature to the jtreg plugin.
>
> However, I thought what I have currently is useful enough in isolation 
> to start the discussion on this.
>
> Jorn
>
> [1]: 
> https://github.com/openjdk/jtreg/compare/master...JornVernee:jtreg:RunMethods
>

From jorn.vernee at oracle.com  Tue Jan  7 17:05:40 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 7 Jan 2025 18:05:40 +0100
Subject: RFC: jtreg IntelliJ plugin: run individual test methods
Message-ID: <1aba836c-cc85-4323-abba-ee8a674aaac5@oracle.com>

Hello,

Jtreg has for a while now had the ability to attach a query string to 
the name of a test, which then gets used by the JUnit or TestNG runner 
to select a particular test method to run.

The intellij plugin currently doesn't have support for specifying a 
query string, or running individual test methods, so I've put together a 
patch that adds that support [1]. This support has two parts: add a 
'Query String' field to the jtreg test configuration window in intellij, 
and automatically populate the query string when creating a test 
configuration from a test method in a source file.

Most of this is pretty straightforward. I did run into a small issue: 
when a method takes parameters, junit requires the parameter types the 
be specified as binary names. It takes some work to derive the binary 
name of the parameter types from the source AST representation exposed 
by intellij to the plugin.

Additionally, I had to amend the format of the query strings accepted by 
the TestNG and JUnit runners to accept a trailing list of parameter type 
names. The new format of the query string is:

<methodName>[-<parameterTypeName>[...,<parameterTypeName>]]

Does this?seem like a good approach?

Future enhancements could include:

1.) displaying individual test methods as results in the intellij UI. 
The problem with doing this is currently that jtreg does not forward the 
results from JUnit/TestNG to the observer the plugin attaches to jtreg. 
Adding support for this seems straightforward enough. Potentially it 
would also be useful to 'itemize' other steps that a jtreg test takes, 
such as compiling, or individual @run tags.
2.) for parameterized tests, the TestNG runner that comes with intellij 
shows each case?(i.e. combination of paramters) individually as a result 
in the UI, and allows re-running just a single case through a unique ID. 
I think JUnit has similar support for this. We could add a similar 
feature to the jtreg plugin.

However, I thought what I have currently is useful enough in isolation 
to start the discussion on this.

Jorn

[1]: 
https://github.com/openjdk/jtreg/compare/master...JornVernee:jtreg:RunMethods


From jorn.vernee at oracle.com  Tue Jan  7 17:33:36 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 7 Jan 2025 18:33:36 +0100
Subject: RFC: jtreg IntelliJ plugin: run individual test methods
In-Reply-To: <c005c6d6-b0b2-4d53-9449-72bce1dc503b@oracle.com>
References: <1aba836c-cc85-4323-abba-ee8a674aaac5@oracle.com>
 <c005c6d6-b0b2-4d53-9449-72bce1dc503b@oracle.com>
Message-ID: <bed45e5d-febb-4057-afb7-37e9214ffc9b@oracle.com>

Unfortunately without support for parameter type names, JUnit test 
methods that accept parameters will not work at all. i.e. it is not just 
about overload selection. If the parameter types are not specified, 
JUnit will look for a method taking no parameters.

Note, though, that I'm not just using a string-based heuristic to derive 
the binary name. Intellij actually has facilities to resolve a source 
name + resolution scope into a 'PsiClass'. The issue is just that there 
is no straightforward way to get a binary name from a PsiClass. So, for 
nested classes I am reconstructing the binary name manually from the 
fully qualified name, and replacing dots with dollars in the name based 
on the actual enclosing classes of the type.

Jorn

On 7-1-2025 18:24, Maurizio Cimadamore wrote:
> Hi Jorn,
> your extension to the plugin seems a fine idea - it would be nice to 
> be able to run specific methods through the plugin.
>
> IMHO, adding parameter types might be a step too far - the general 
> problem of "predicting" which binary name a source class name might 
> have is rather hard, and it amounts at heuristics (e.g. there's more 
> to it than just replacing dots with dollars, as you also take into 
> account as to whether other class declared with a dollar in their name 
> (!!) are present).
>
> I wonder if a sensible first step would be to just support the same 
> logic that jtreg runners also support -- e.g. just a method name. 
> After all, it is extremely unlikely to have overloaded test methods. 
> E.g. it seems to me that we're in a case where we can get almost all 
> the benefit at a fraction of the complexity.
>
> What do you think?
>
> Maurizio
>
> On 07/01/2025 17:05, Jorn Vernee wrote:
>> Hello,
>>
>> Jtreg has for a while now had the ability to attach a query string to 
>> the name of a test, which then gets used by the JUnit or TestNG 
>> runner to select a particular test method to run.
>>
>> The intellij plugin currently doesn't have support for specifying a 
>> query string, or running individual test methods, so I've put 
>> together a patch that adds that support [1]. This support has two 
>> parts: add a 'Query String' field to the jtreg test configuration 
>> window in intellij, and automatically populate the query string when 
>> creating a test configuration from a test method in a source file.
>>
>> Most of this is pretty straightforward. I did run into a small issue: 
>> when a method takes parameters, junit requires the parameter types 
>> the be specified as binary names. It takes some work to derive the 
>> binary name of the parameter types from the source AST representation 
>> exposed by intellij to the plugin.
>>
>> Additionally, I had to amend the format of the query strings accepted 
>> by the TestNG and JUnit runners to accept a trailing list of 
>> parameter type names. The new format of the query string is:
>>
>> <methodName>[-<parameterTypeName>[...,<parameterTypeName>]]
>>
>> Does this?seem like a good approach?
>>
>> Future enhancements could include:
>>
>> 1.) displaying individual test methods as results in the intellij UI. 
>> The problem with doing this is currently that jtreg does not forward 
>> the results from JUnit/TestNG to the observer the plugin attaches to 
>> jtreg. Adding support for this seems straightforward enough. 
>> Potentially it would also be useful to 'itemize' other steps that a 
>> jtreg test takes, such as compiling, or individual @run tags.
>> 2.) for parameterized tests, the TestNG runner that comes with 
>> intellij shows each case?(i.e. combination of paramters) individually 
>> as a result in the UI, and allows re-running just a single case 
>> through a unique ID. I think JUnit has similar support for this. We 
>> could add a similar feature to the jtreg plugin.
>>
>> However, I thought what I have currently is useful enough in 
>> isolation to start the discussion on this.
>>
>> Jorn
>>
>> [1]: 
>> https://github.com/openjdk/jtreg/compare/master...JornVernee:jtreg:RunMethods
>>

From jorn.vernee at oracle.com  Wed Jan  8 15:05:07 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Wed, 8 Jan 2025 16:05:07 +0100
Subject: RFC: jtreg IntelliJ plugin: run individual test methods
In-Reply-To: <bed45e5d-febb-4057-afb7-37e9214ffc9b@oracle.com>
References: <1aba836c-cc85-4323-abba-ee8a674aaac5@oracle.com>
 <c005c6d6-b0b2-4d53-9449-72bce1dc503b@oracle.com>
 <bed45e5d-febb-4057-afb7-37e9214ffc9b@oracle.com>
Message-ID: <055545d3-ab29-4013-bdf5-339146357f32@oracle.com>

I've found an additional issue with the current query string format: it 
does not support @Nested JUnit test classes (which we're actually using 
in practice at the moment in the project I'm working on), because the 
JUnit runner currently always passed the top-level class name to JUnit, 
rather than the class name of the @Nested class.

So, if we want to support selecting methods in nested test classes as 
well, we need to incorporate the class name in the query string. In that 
case, I suggest the following format:

<className>::<methodName>[(<parameterTypeName>[...,<parameterTypeName>])]

Where, by default, an absent/empty query string will just select the 
class specified by the @run tag. (We could also make the `<className>::` 
prefix optional, I think)

I've pushed an update which implements this, if you want to check it out.

Jorn

On 7-1-2025 18:33, Jorn Vernee wrote:
> Unfortunately without support for parameter type names, JUnit test 
> methods that accept parameters will not work at all. i.e. it is not 
> just about overload selection. If the parameter types are not 
> specified, JUnit will look for a method taking no parameters.
>
> Note, though, that I'm not just using a string-based heuristic to 
> derive the binary name. Intellij actually has facilities to resolve a 
> source name + resolution scope into a 'PsiClass'. The issue is just 
> that there is no straightforward way to get a binary name from a 
> PsiClass. So, for nested classes I am reconstructing the binary name 
> manually from the fully qualified name, and replacing dots with 
> dollars in the name based on the actual enclosing classes of the type.
>
> Jorn
>
> On 7-1-2025 18:24, Maurizio Cimadamore wrote:
>> Hi Jorn,
>> your extension to the plugin seems a fine idea - it would be nice to 
>> be able to run specific methods through the plugin.
>>
>> IMHO, adding parameter types might be a step too far - the general 
>> problem of "predicting" which binary name a source class name might 
>> have is rather hard, and it amounts at heuristics (e.g. there's more 
>> to it than just replacing dots with dollars, as you also take into 
>> account as to whether other class declared with a dollar in their 
>> name (!!) are present).
>>
>> I wonder if a sensible first step would be to just support the same 
>> logic that jtreg runners also support -- e.g. just a method name. 
>> After all, it is extremely unlikely to have overloaded test methods. 
>> E.g. it seems to me that we're in a case where we can get almost all 
>> the benefit at a fraction of the complexity.
>>
>> What do you think?
>>
>> Maurizio
>>
>> On 07/01/2025 17:05, Jorn Vernee wrote:
>>> Hello,
>>>
>>> Jtreg has for a while now had the ability to attach a query string 
>>> to the name of a test, which then gets used by the JUnit or TestNG 
>>> runner to select a particular test method to run.
>>>
>>> The intellij plugin currently doesn't have support for specifying a 
>>> query string, or running individual test methods, so I've put 
>>> together a patch that adds that support [1]. This support has two 
>>> parts: add a 'Query String' field to the jtreg test configuration 
>>> window in intellij, and automatically populate the query string when 
>>> creating a test configuration from a test method in a source file.
>>>
>>> Most of this is pretty straightforward. I did run into a small 
>>> issue: when a method takes parameters, junit requires the parameter 
>>> types the be specified as binary names. It takes some work to derive 
>>> the binary name of the parameter types from the source AST 
>>> representation exposed by intellij to the plugin.
>>>
>>> Additionally, I had to amend the format of the query strings 
>>> accepted by the TestNG and JUnit runners to accept a trailing list 
>>> of parameter type names. The new format of the query string is:
>>>
>>> <methodName>[-<parameterTypeName>[...,<parameterTypeName>]]
>>>
>>> Does this?seem like a good approach?
>>>
>>> Future enhancements could include:
>>>
>>> 1.) displaying individual test methods as results in the intellij 
>>> UI. The problem with doing this is currently that jtreg does not 
>>> forward the results from JUnit/TestNG to the observer the plugin 
>>> attaches to jtreg. Adding support for this seems straightforward 
>>> enough. Potentially it would also be useful to 'itemize' other steps 
>>> that a jtreg test takes, such as compiling, or individual @run tags.
>>> 2.) for parameterized tests, the TestNG runner that comes with 
>>> intellij shows each case?(i.e. combination of paramters) 
>>> individually as a result in the UI, and allows re-running just a 
>>> single case through a unique ID. I think JUnit has similar support 
>>> for this. We could add a similar feature to the jtreg plugin.
>>>
>>> However, I thought what I have currently is useful enough in 
>>> isolation to start the discussion on this.
>>>
>>> Jorn
>>>
>>> [1]: 
>>> https://github.com/openjdk/jtreg/compare/master...JornVernee:jtreg:RunMethods
>>>

From jvernee at openjdk.org  Mon Jan 13 13:31:29 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 13 Jan 2025 13:31:29 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes
Message-ID: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>

See the JBS issue for an extended problem description.

This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by extending the format that a query string can have. The new proposed format is as follows:


<class name>[::<method name>([<param type>[...,<param type>]])]


For example, running a method `foo` that takes no parameters would be done using `<test name>?TestClass::foo()`. If `foo` has parameters, then at least for JUnit tests they have to be specified as a comma separated list of binary names between the parentheses. For example:


TestDowncallScope::testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)


The delimiting characters I choose here `::` and `(...)` have to be quoted when passed through most shells. If this is deemed to be an issue, we could also change the separators for class name/method name/parameters to simple hyphens. Although, in cases where a `$` sign appears in the binary name of a nested class, quoting would be needed either way. (I would personally choose to always quote the argument, just to be sure, so I don't mind using `::` and `(...)`).

This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).

Testing: I've added additional tests for the new cases (as far as I know, TestNG does not support nested test classes though). I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

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

Commit messages:
 - Support running individual parameterized methods & nested test classes

Changes: https://git.openjdk.org/jtreg/pull/241/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=241&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903930
  Stats: 325 lines in 8 files changed: 269 ins; 5 del; 51 mod
  Patch: https://git.openjdk.org/jtreg/pull/241.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/241/head:pull/241

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

From lmesnik at openjdk.org  Tue Jan 14 04:11:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 14 Jan 2025 04:11:29 GMT
Subject: RFR: 7903931: Add "jtreg.ttf" property to filter tests based on test
 thread factory value
Message-ID: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>

jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.

Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.

So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.

The only jtreg knows if -testThreadFactory is set so it should set corresponding property

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

Commit messages:
 - Add "jtreg.ttf" property to filter tests based on test thread factory value

Changes: https://git.openjdk.org/jtreg/pull/242/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=242&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903931
  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/242.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/242/head:pull/242

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

From cstein at openjdk.org  Tue Jan 14 15:43:10 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 14 Jan 2025 15:43:10 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <swV5znXTkzthI1LIGyAgdCTd2UA0_DZsXQrzHKwWMw4=.1e7341d2-2f39-48db-8dbc-965e8fd22c2d@github.com>

On Mon, 13 Jan 2025 13:19:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by extending the format that a query string can have. The new proposed format is as follows:
> 
> 
> <class name>[::<method name>([<param type>[...,<param type>]])]
> 
> 
> For example, running a method `foo` that takes no parameters would be done using `<test name>?TestClass::foo()`. If `foo` has parameters, then at least for JUnit tests they have to be specified as a comma separated list of binary names between the parentheses. For example:
> 
> 
> TestDowncallScope::testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> The delimiting characters I choose here `::` and `(...)` have to be quoted when passed through most shells. If this is deemed to be an issue, we could also change the separators for class name/method name/parameters to simple hyphens. Although, in cases where a `$` sign appears in the binary name of a nested class, quoting would be needed either way. (I would personally choose to always quote the argument, just to be sure, so I don't mind using `::` and `(...)`).
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases (as far as I know, TestNG does not support nested test classes though). I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

Implementation and associated tests look good on first sight! Will do some local experiments tomorrow.

Please, also update related sections/phrases in the FAQ document, for example: 
- https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#how-do-i-specify-which-tests-to-run
- https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#how-do-i-run-a-single-test-method-in-a-junit-test

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

PR Comment: https://git.openjdk.org/jtreg/pull/241#issuecomment-2590283225

From jvernee at openjdk.org  Tue Jan 14 16:28:20 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Jan 2025 16:28:20 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v2]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <RFzPGHfY1KAcPMOdMW_OhrVnitRmLCxkClZVnQEvAEU=.c4bc21f2-03fd-42fa-a0db-c2aabf479e5b@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by extending the format that a query string can have. The new proposed format is as follows:
> 
> 
> <class name>[::<method name>([<param type>[...,<param type>]])]
> 
> 
> For example, running a method `foo` that takes no parameters would be done using `<test name>?TestClass::foo()`. If `foo` has parameters, then at least for JUnit tests they have to be specified as a comma separated list of binary names between the parentheses. For example:
> 
> 
> TestDowncallScope::testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> The delimiting characters I choose here `::` and `(...)` have to be quoted when passed through most shells. If this is deemed to be an issue, we could also change the separators for class name/method name/parameters to simple hyphens. Although, in cases where a `$` sign appears in the binary name of a nested class, quoting would be needed either way. (I would personally choose to always quote the argument, just to be sure, so I don't mind using `::` and `(...)`).
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases (as far as I know, TestNG does not support nested test classes though). I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

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

  update FAQ

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/6149386a..54d91bde

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

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

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

From jvernee at openjdk.org  Tue Jan 14 16:28:20 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Jan 2025 16:28:20 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <I7folY4Q_Sj6hoTErQBctLPS__5momhycEvmdy69ZVw=.b153b8d2-e8da-4916-b188-d21c77997c11@github.com>

On Mon, 13 Jan 2025 13:19:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by extending the format that a query string can have. The new proposed format is as follows:
> 
> 
> <class name>[::<method name>([<param type>[...,<param type>]])]
> 
> 
> For example, running a method `foo` that takes no parameters would be done using `<test name>?TestClass::foo()`. If `foo` has parameters, then at least for JUnit tests they have to be specified as a comma separated list of binary names between the parentheses. For example:
> 
> 
> TestDowncallScope::testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> The delimiting characters I choose here `::` and `(...)` have to be quoted when passed through most shells. If this is deemed to be an issue, we could also change the separators for class name/method name/parameters to simple hyphens. Although, in cases where a `$` sign appears in the binary name of a nested class, quoting would be needed either way. (I would personally choose to always quote the argument, just to be sure, so I don't mind using `::` and `(...)`).
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases (as far as I know, TestNG does not support nested test classes though). I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

I've updated the FAQ. See: https://github.com/openjdk/jtreg/pull/241/commits/54d91bde8fdc0993866dc3cd1886909dec38ab7e

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

PR Comment: https://git.openjdk.org/jtreg/pull/241#issuecomment-2590446936

From jvernee at openjdk.org  Tue Jan 14 17:35:21 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Jan 2025 17:35:21 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v3]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <_Ux0FYYlE2xAQ3pcO5SiKkkjjwTDeAXKU9B2abyAw9E=.cbd124cc-040d-4adb-bdba-5808ea9b3e6b@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by extending the format that a query string can have. The new proposed format is as follows:
> 
> 
> <class name>[::<method name>([<param type>[...,<param type>]])]
> 
> 
> For example, running a method `foo` that takes no parameters would be done using `<test name>?TestClass::foo()`. If `foo` has parameters, then at least for JUnit tests they have to be specified as a comma separated list of binary names between the parentheses. For example:
> 
> 
> TestDowncallScope::testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> The delimiting characters I choose here `::` and `(...)` have to be quoted when passed through most shells. If this is deemed to be an issue, we could also change the separators for class name/method name/parameters to simple hyphens. Although, in cases where a `$` sign appears in the binary name of a nested class, quoting would be needed either way. (I would personally choose to always quote the argument, just to be sure, so I don't mind using `::` and `(...)`).
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases (as far as I know, TestNG does not support nested test classes though). I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - Rely on junit selector parsing support
 - Revert "Support running individual parameterized methods & nested test classes"
   
   Revert TestNG related changes

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/54d91bde..d322a2c4

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

  Stats: 231 lines in 7 files changed: 11 ins; 167 del; 53 mod
  Patch: https://git.openjdk.org/jtreg/pull/241.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/241/head:pull/241

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

From jvernee at openjdk.org  Tue Jan 14 18:03:32 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Jan 2025 18:03:32 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v4]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <l2wIqVRverF8_G1pZX52rsRNkxouHwC1C-GMAL9uO4E=.fb0cd4d5-2146-4df8-b62f-127327901c8b@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by extending the format that a query string can have. The new proposed format is as follows:
> 
> 
> <class name>[::<method name>([<param type>[...,<param type>]])]
> 
> 
> For example, running a method `foo` that takes no parameters would be done using `<test name>?TestClass::foo()`. If `foo` has parameters, then at least for JUnit tests they have to be specified as a comma separated list of binary names between the parentheses. For example:
> 
> 
> TestDowncallScope::testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> The delimiting characters I choose here `::` and `(...)` have to be quoted when passed through most shells. If this is deemed to be an issue, we could also change the separators for class name/method name/parameters to simple hyphens. Although, in cases where a `$` sign appears in the binary name of a nested class, quoting would be needed either way. (I would personally choose to always quote the argument, just to be sure, so I don't mind using `::` and `(...)`).
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases (as far as I know, TestNG does not support nested test classes though). I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - update FAQ
 - cleanup test

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/d322a2c4..e5c37280

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

  Stats: 33 lines in 3 files changed: 8 ins; 2 del; 23 mod
  Patch: https://git.openjdk.org/jtreg/pull/241.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/241/head:pull/241

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

From jvernee at openjdk.org  Tue Jan 14 18:09:06 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Jan 2025 18:09:06 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v4]
In-Reply-To: <l2wIqVRverF8_G1pZX52rsRNkxouHwC1C-GMAL9uO4E=.fb0cd4d5-2146-4df8-b62f-127327901c8b@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <l2wIqVRverF8_G1pZX52rsRNkxouHwC1C-GMAL9uO4E=.fb0cd4d5-2146-4df8-b62f-127327901c8b@github.com>
Message-ID: <8xs5vs2TGxVHNLCT8vyT76BTLQWPYW09Mo6ph_LUHU0=.a2b647d8-c9ac-4465-ada7-c8872890b87f@github.com>

On Tue, 14 Jan 2025 18:03:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by extending the format that a query string can have. The new proposed format is as follows:
>> 
>> 
>> <class name>[::<method name>([<param type>[...,<param type>]])]
>> 
>> 
>> For example, running a method `foo` that takes no parameters would be done using `<test name>?TestClass::foo()`. If `foo` has parameters, then at least for JUnit tests they have to be specified as a comma separated list of binary names between the parentheses. For example:
>> 
>> 
>> TestDowncallScope::testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> The delimiting characters I choose here `::` and `(...)` have to be quoted when passed through most shells. If this is deemed to be an issue, we could also change the separators for class name/method name/parameters to simple hyphens. Although, in cases where a `$` sign appears in the binary name of a nested class, quoting would be needed either way. (I would personally choose to always quote the argument, just to be sure, so I don't mind using `::` and `(...)`).
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases (as far as I know, TestNG does not support nested test classes though). I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update FAQ
>  - cleanup test

Some results of offline discussion:

- We'd like to rely on JUnit's builtin support for parsing these queries, so we don't have to implement our own parsing. This also means we can use any JUnit selector (such as uid, to run individual cases of a parameterized test)
- This means that we don't support the extended format for TestNG tests. But, this is okay, since TestNG doesn't support nested test classes any way, and we don't need to specify the parameter types to select a parameterized method
- To use the junit selector support, the query string is prefixed with `junit-select:`, and then an identifier such as the ones listed [here](https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors) is used as a suffix.
- The current format, with just the method name, continues to work as well.

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

PR Comment: https://git.openjdk.org/jtreg/pull/241#issuecomment-2590752416

From jvernee at openjdk.org  Fri Jan 17 16:19:29 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Jan 2025 16:19:29 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v5]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <gDbKT1gSVNdsBkoUJAszFM5tSWWwhiC3vfUqtAHg7_I=.841ad372-d5e5-4fda-8c2d-268f970a621b@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
> 
> 
> junit-select:<selector>
> 
> 
> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
> 
> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
> 
> 
> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

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

  exclude '?' from directory pattern, so as not to confuse query strings from group specs

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/e5c37280..914f0303

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

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

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

From jvernee at openjdk.org  Fri Jan 17 16:36:35 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Jan 2025 16:36:35 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v6]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <7q3Da2kK9nDF4tdcUmwnmFo0vnxyFYUYoERYX2wChkA=.73195775-11bb-4515-8e3a-19bbabdc854a@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
> 
> 
> junit-select:<selector>
> 
> 
> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
> 
> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
> 
> 
> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

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

  add test case for prior fix

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/914f0303..072b0397

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

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

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

From cstein at openjdk.org  Mon Jan 20 16:26:53 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 20 Jan 2025 16:26:53 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v6]
In-Reply-To: <7q3Da2kK9nDF4tdcUmwnmFo0vnxyFYUYoERYX2wChkA=.73195775-11bb-4515-8e3a-19bbabdc854a@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <7q3Da2kK9nDF4tdcUmwnmFo0vnxyFYUYoERYX2wChkA=.73195775-11bb-4515-8e3a-19bbabdc854a@github.com>
Message-ID: <iMi3Jd50JSPAOazXw-Q3GQgB7yYSuCexocvcg6pet5w=.a75a1cd6-e958-474d-9030-2a86424dd593@github.com>

On Fri, 17 Jan 2025 16:36:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
>> 
>> 
>> junit-select:<selector>
>> 
>> 
>> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
>> 
>> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
>> 
>> 
>> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test case for prior fix

Thanks for implementing this feature, Jorn, with updates to the FAQ and tests.

Nit: please delete unused import statements and add a line to the `CHANGELOG.md` file

src/share/classes/com/sun/javatest/regtest/agent/JUnitRunner.java line 50:

> 48: import java.lang.reflect.Method;
> 49: import java.time.Duration;
> 50: import java.util.List;

Remove unused import statement.

Suggestion:

src/share/classes/com/sun/javatest/regtest/agent/JUnitRunner.java line 56:

> 54: import java.util.concurrent.locks.Lock;
> 55: import java.util.concurrent.locks.ReentrantLock;
> 56: import java.util.stream.Collectors;

Remove unused import statement.

Suggestion:

src/share/classes/com/sun/javatest/regtest/config/TestManager.java line 112:

> 110:         static final Pattern groupPtn = System.getProperty("os.name").matches("(?i)windows.*")
> 111:                 ? Pattern.compile("(?<dir>|[^A-Za-z?]|[^?]{2,}):(?<group>[A-Za-z0-9_,]+)")
> 112:                 : Pattern.compile("(?<dir>[^?]*):(?<group>[A-Za-z0-9_,]+)");

Good improvement!

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

Changes requested by cstein (Committer).

PR Review: https://git.openjdk.org/jtreg/pull/241#pullrequestreview-2562779875
PR Review Comment: https://git.openjdk.org/jtreg/pull/241#discussion_r1922634512
PR Review Comment: https://git.openjdk.org/jtreg/pull/241#discussion_r1922634670
PR Review Comment: https://git.openjdk.org/jtreg/pull/241#discussion_r1922635436

From jvernee at openjdk.org  Mon Jan 20 16:49:27 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 20 Jan 2025 16:49:27 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v7]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <CktzB193rPJAZwC361V4IvZx-RqkZDNMB3ikuBswpLc=.03e11522-2b35-447b-932a-e0e57e6abd8f@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
> 
> 
> junit-select:<selector>
> 
> 
> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
> 
> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
> 
> 
> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

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

  Remove dangling imports
  
  Co-authored-by: Christian Stein <sormuras at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/072b0397..0ccb562c

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

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

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

From duke at openjdk.org  Mon Jan 20 16:49:29 2025
From: duke at openjdk.org (Sam Brannen)
Date: Mon, 20 Jan 2025 16:49:29 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v6]
In-Reply-To: <7q3Da2kK9nDF4tdcUmwnmFo0vnxyFYUYoERYX2wChkA=.73195775-11bb-4515-8e3a-19bbabdc854a@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <7q3Da2kK9nDF4tdcUmwnmFo0vnxyFYUYoERYX2wChkA=.73195775-11bb-4515-8e3a-19bbabdc854a@github.com>
Message-ID: <zWUwQ8YhWPJhZcp4xNpzA-gxJsPDS2UfiCRDrcgnVj4=.b0af28fa-fb07-4745-a6ee-52c1ec5ba014@github.com>

On Fri, 17 Jan 2025 16:36:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
>> 
>> 
>> junit-select:<selector>
>> 
>> 
>> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
>> 
>> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
>> 
>> 
>> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test case for prior fix

> If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names.

For array types, I believe that canonical names are also supported -- for example, `int[][]`, `java.lang.String[]`, etc., which might prove beneficial if any of those queries are hand crafted.

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

PR Comment: https://git.openjdk.org/jtreg/pull/241#issuecomment-2602877870

From jvernee at openjdk.org  Mon Jan 20 16:54:04 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 20 Jan 2025 16:54:04 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v8]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <OLWvsobky3DbONih82mT31UvSusXmcR0XPSAnUt973g=.63600df5-66b7-4363-8e4c-ad89851e5add@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
> 
> 
> junit-select:<selector>
> 
> 
> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
> 
> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
> 
> 
> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

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

  update changelog

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/0ccb562c..d6be9d99

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

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

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

From jvernee at openjdk.org  Mon Jan 20 16:56:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 20 Jan 2025 16:56:50 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v6]
In-Reply-To: <zWUwQ8YhWPJhZcp4xNpzA-gxJsPDS2UfiCRDrcgnVj4=.b0af28fa-fb07-4745-a6ee-52c1ec5ba014@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <7q3Da2kK9nDF4tdcUmwnmFo0vnxyFYUYoERYX2wChkA=.73195775-11bb-4515-8e3a-19bbabdc854a@github.com>
 <zWUwQ8YhWPJhZcp4xNpzA-gxJsPDS2UfiCRDrcgnVj4=.b0af28fa-fb07-4745-a6ee-52c1ec5ba014@github.com>
Message-ID: <mDAhOnALN5FoSRLX1YDzr0kADdZrlFM9O829QajI2TU=.e459e84d-357d-40ef-8c99-69dade7f6f90@github.com>

On Mon, 20 Jan 2025 16:46:12 GMT, Sam Brannen <duke at openjdk.org> wrote:

> > If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names.
> 
> For array types, I believe that canonical names are also supported -- for example, `int[][]`, `java.lang.String[]`, etc., which might prove beneficial if any of those queries are hand crafted.

Yes, that's a good point. I think the main user of this will be the intellij plugin, which will automatically derive the query string, but it wouldn't hurt to mention this in the FAQ. I'll try to see if there's a JUnit doc section that describes the supported format, and we could just link to that.

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

PR Comment: https://git.openjdk.org/jtreg/pull/241#issuecomment-2602893943

From jvernee at openjdk.org  Mon Jan 20 17:06:49 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 20 Jan 2025 17:06:49 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v8]
In-Reply-To: <OLWvsobky3DbONih82mT31UvSusXmcR0XPSAnUt973g=.63600df5-66b7-4363-8e4c-ad89851e5add@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <OLWvsobky3DbONih82mT31UvSusXmcR0XPSAnUt973g=.63600df5-66b7-4363-8e4c-ad89851e5add@github.com>
Message-ID: <QXvDkQvxoPlDQkTiSrFxIKqtQ7cntvrpyEPGW3W_bd4=.e7b95902-b8c9-4456-8940-87bb594609d5@github.com>

On Mon, 20 Jan 2025 16:54:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
>> 
>> 
>> junit-select:<selector>
>> 
>> 
>> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
>> 
>> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
>> 
>> 
>> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update changelog

I noticed that there's also a `nested-class` and `nested-method` selector. Is there a reason for keeping these separate? Or is it fine to use the `class` and `method` selectors as well, which work as long as you use the binary name of the nested class.

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

PR Comment: https://git.openjdk.org/jtreg/pull/241#issuecomment-2602913438

From cstein at openjdk.org  Mon Jan 20 17:18:53 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 20 Jan 2025 17:18:53 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v8]
In-Reply-To: <QXvDkQvxoPlDQkTiSrFxIKqtQ7cntvrpyEPGW3W_bd4=.e7b95902-b8c9-4456-8940-87bb594609d5@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <OLWvsobky3DbONih82mT31UvSusXmcR0XPSAnUt973g=.63600df5-66b7-4363-8e4c-ad89851e5add@github.com>
 <QXvDkQvxoPlDQkTiSrFxIKqtQ7cntvrpyEPGW3W_bd4=.e7b95902-b8c9-4456-8940-87bb594609d5@github.com>
Message-ID: <VZfQpIg8vgqJwYZHgli9SshTrUCoSamlD_gTNDHsvXI=.deb14e4c-dc96-4667-b690-e8955c035d94@github.com>

On Mon, 20 Jan 2025 17:04:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I noticed that there's also a nested-class and nested-method selector. Is there a reason for keeping these separate? Or is it fine to use the class and method selectors as well, which work as long as you use the binary name of the nested class?

Binary names for classes and nested classes are fine. These two nested variants can be used for "lazy load" scenarios. See for example the API documentation of `NestedMethodSelector`
> A [DiscoverySelector](https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/DiscoverySelector.html) that selects a nested [Method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Method.html) or a combination of enclosing classes names, class name, method name, and parameter types so that [TestEngines](https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/TestEngine.html) can discover tests or containers based on methods.
If a Java [Method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Method.html) is provided, the selector will return that [method](https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedMethodSelector.html#getMethod()) and its method name, class name, enclosing classes names, and parameter types accordingly. If class names or method names are provided, this selector will only attempt to lazily load a class or method if [getEnclosingClasses()](https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedMethodSelector.html#getEnclosingClasses()), [getNestedClass()](https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedMethodSelector.html#getNestedClass()), [getMethod()](https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedMethodSelector.htm
 l#getMethod()), or [getParameterTypes()](https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedMethodSelector.html#getParameterTypes()) is invoked.

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

PR Comment: https://git.openjdk.org/jtreg/pull/241#issuecomment-2602934527

From jvernee at openjdk.org  Mon Jan 20 17:58:09 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 20 Jan 2025 17:58:09 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v9]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <2EWCeDBbE73PYSpEzKvNkDPpdIz03mWoLrARQ7qR99w=.84cd8b1e-0695-4b1a-979b-5bb49ad387b7@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
> 
> 
> junit-select:<selector>
> 
> 
> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
> 
> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
> 
> 
> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - fix typo
 - update FAQ to link to JUnit doc

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/d6be9d99..a90a014a

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

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

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

From jvernee at openjdk.org  Mon Jan 20 17:58:09 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 20 Jan 2025 17:58:09 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v8]
In-Reply-To: <OLWvsobky3DbONih82mT31UvSusXmcR0XPSAnUt973g=.63600df5-66b7-4363-8e4c-ad89851e5add@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <OLWvsobky3DbONih82mT31UvSusXmcR0XPSAnUt973g=.63600df5-66b7-4363-8e4c-ad89851e5add@github.com>
Message-ID: <hjLC3Q7r9UEs2H2w_jBCzyc5EdNj-Rrp4_jfw6fT4_A=.ec6d9973-1cad-4c03-9c58-60381a174f8c@github.com>

On Mon, 20 Jan 2025 16:54:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
>> 
>> 
>> junit-select:<selector>
>> 
>> 
>> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
>> 
>> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
>> 
>> 
>> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update changelog

I've updated the FAQ to link to the doc of `DiscoverySelectors#selectMethod(java.lang.String)`

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

PR Comment: https://git.openjdk.org/jtreg/pull/241#issuecomment-2602994530

From cstein at openjdk.org  Tue Jan 21 08:03:52 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 21 Jan 2025 08:03:52 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v9]
In-Reply-To: <2EWCeDBbE73PYSpEzKvNkDPpdIz03mWoLrARQ7qR99w=.84cd8b1e-0695-4b1a-979b-5bb49ad387b7@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <2EWCeDBbE73PYSpEzKvNkDPpdIz03mWoLrARQ7qR99w=.84cd8b1e-0695-4b1a-979b-5bb49ad387b7@github.com>
Message-ID: <63GUhaFpIc1snT7j_YmjBCjKNoCrpp6ywnvdbfHqH_M=.b1596d08-e6f3-492a-b9a7-228515e59939@github.com>

On Mon, 20 Jan 2025 17:58:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
>> 
>> 
>> junit-select:<selector>
>> 
>> 
>> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
>> 
>> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
>> 
>> 
>> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix typo
>  - update FAQ to link to JUnit doc

Looks good to me.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jtreg/pull/241#pullrequestreview-2563734148

From jpai at openjdk.org  Tue Jan 21 08:33:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Jan 2025 08:33:50 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v9]
In-Reply-To: <2EWCeDBbE73PYSpEzKvNkDPpdIz03mWoLrARQ7qR99w=.84cd8b1e-0695-4b1a-979b-5bb49ad387b7@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <2EWCeDBbE73PYSpEzKvNkDPpdIz03mWoLrARQ7qR99w=.84cd8b1e-0695-4b1a-979b-5bb49ad387b7@github.com>
Message-ID: <WAaZaVU21C2YulCqUagT-9WS-_7kyBtM3kU9yDL9EoE=.9248bfcc-40e0-4325-ba3b-bbdc52d63449@github.com>

On Mon, 20 Jan 2025 17:58:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
>> 
>> 
>> junit-select:<selector>
>> 
>> 
>> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
>> 
>> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
>> 
>> 
>> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix typo
>  - update FAQ to link to JUnit doc

Hello Jorn, these changes look reasonable to me.

Several of these files will need a copyright year update before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/241#pullrequestreview-2563818756

From jvernee at openjdk.org  Tue Jan 21 11:53:05 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 21 Jan 2025 11:53:05 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v10]
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <arSj9jXLnN6GrmX-8eSfV5DMxFgQccb1zt5nunPiquQ=.851629f2-62ed-4856-9e2d-c0197893f0dc@github.com>

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
> 
> 
> junit-select:<selector>
> 
> 
> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
> 
> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
> 
> 
> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

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

  Update copyright years

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/241/files
  - new: https://git.openjdk.org/jtreg/pull/241/files/a90a014a..a5259473

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

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

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

From cstein at openjdk.org  Tue Jan 21 11:53:05 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 21 Jan 2025 11:53:05 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v10]
In-Reply-To: <arSj9jXLnN6GrmX-8eSfV5DMxFgQccb1zt5nunPiquQ=.851629f2-62ed-4856-9e2d-c0197893f0dc@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <arSj9jXLnN6GrmX-8eSfV5DMxFgQccb1zt5nunPiquQ=.851629f2-62ed-4856-9e2d-c0197893f0dc@github.com>
Message-ID: <589aKlWrGlQh1mw6YG5PBunBHJCErFfKpjEwb5X2OoA=.fcaf6925-c49a-4d8c-b57b-6ffaf768cd2b@github.com>

On Tue, 21 Jan 2025 11:50:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
>> 
>> 
>> junit-select:<selector>
>> 
>> 
>> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
>> 
>> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
>> 
>> 
>> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jtreg/pull/241#pullrequestreview-2564374162

From jpai at openjdk.org  Tue Jan 21 11:55:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Jan 2025 11:55:50 GMT
Subject: RFR: 7903930: Support running individual parameterized tests and
 @Nested test classes [v10]
In-Reply-To: <arSj9jXLnN6GrmX-8eSfV5DMxFgQccb1zt5nunPiquQ=.851629f2-62ed-4856-9e2d-c0197893f0dc@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
 <arSj9jXLnN6GrmX-8eSfV5DMxFgQccb1zt5nunPiquQ=.851629f2-62ed-4856-9e2d-c0197893f0dc@github.com>
Message-ID: <bHYCfeT222BSBFrQdGmQZt0M-91c-_tLWjMD2rGAvjw=.8b8385a8-c67d-4ba4-9d0d-2b64940605c3@github.com>

On Tue, 21 Jan 2025 11:53:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for an extended problem description.
>> 
>> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
>> 
>> 
>> junit-select:<selector>
>> 
>> 
>> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
>> 
>> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
>> 
>> 
>> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
>> 
>> 
>> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
>> 
>> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/241#pullrequestreview-2564383414

From jvernee at openjdk.org  Tue Jan 21 12:33:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 21 Jan 2025 12:33:50 GMT
Subject: Integrated: 7903930: Support running individual parameterized tests
 and @Nested test classes
In-Reply-To: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
References: <65te336PFkb6ShwJdMqy4mYRgox_M6lpXEUiBqrVUkM=.3fe9b91d-e102-42e8-b6b5-e226a71ba16f@github.com>
Message-ID: <QaUVlqyN7qz0i2TMPYi7FFtEVryV_IRKYQQzXwyYxK8=.28017dc8-9ffb-4f2f-a6d3-bf79a49c9612@github.com>

On Mon, 13 Jan 2025 13:19:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> See the JBS issue for an extended problem description.
> 
> This PR adds support for running individual parameterized JUnit test methods, as well as nested test classes, by adding a new flavor of query string, prefixed with `junit-select`:
> 
> 
> junit-select:<selector>
> 
> 
> This intends to take direct advantage of JUnits selector string support. The supported selectors are listed in the column on the right in the table here: https://junit.org/junit5/docs/current/user-guide/#running-tests-discovery-selectors
> 
> For example, running a method `foo` that takes no parameters could be done using `foo`, just like before. If `foo` has parameters, then for JUnit tests they have to be specified as a comma separated list of binary names. For that we can use the `method` selector. For example:
> 
> 
> junit-select:method:TestDowncallScope#testDowncall(int,java.lang.String,CallGeneratorHelper$Ret,java.util.List,java.util.List)
> 
> 
> This support is intended to be used by the intellij plugin to support running individual methods and nested classes (see https://github.com/openjdk/jtreg/pull/240).
> 
> Testing: I've added additional tests for the new cases. I've also been using a PoC of this feature as the basis for similar support in the intellij plugin that I'm working on.

This pull request has now been integrated.

Changeset: b4439732
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/b4439732676ada6bab6366cfef15b4e614964b46
Stats:     178 lines in 6 files changed: 157 ins; 2 del; 19 mod

7903930: Support running individual parameterized tests and @Nested test classes

Reviewed-by: cstein, jpai

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

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

From jvernee at openjdk.org  Tue Jan 21 13:15:23 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 21 Jan 2025 13:15:23 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
Message-ID: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>

This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).

One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that take parameters. So, I had to manually implement this. You'll see this back in the code.

I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.

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

Commit messages:
 - move query string text field + tie to file selection
 - use new query string format
 - Support query string in idea plugin

Changes: https://git.openjdk.org/jtreg/pull/240/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=240&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903934
  Stats: 165 lines in 6 files changed: 138 ins; 9 del; 18 mod
  Patch: https://git.openjdk.org/jtreg/pull/240.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/240/head:pull/240

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

From cstein at openjdk.org  Tue Jan 21 15:59:00 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 21 Jan 2025 15:59:00 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation
In-Reply-To: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
Message-ID: <Yl3tqCu-m1u0y1WgtyXQizG633IcuGPIZ6mhMyaRfqg=.6d22d2eb-c174-4f5c-b586-776e32e39fb7@github.com>

On Tue, 7 Jan 2025 16:04:39 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
> 
> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.

Thanks for the contribution @asilichenko!

- Please update this pull request to also include the changes from #239 and close #239 in favor of this pull request.
- Please update the title of this pull request to read: `7903936: Update variable names in build.sh documentation` , I created https://bugs.openjdk.org/browse/CODETOOLS-7903936 for this renaming task.
- Please update the second year in line 4 of `build.sh` from `2024` to `2025`.

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

PR Comment: https://git.openjdk.org/jtreg/pull/238#issuecomment-2605094427

From duke at openjdk.org  Tue Jan 21 15:59:00 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 21 Jan 2025 15:59:00 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation
Message-ID: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>

Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 

`CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.

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

Commit messages:
 - Merge branch 'openjdk:master' into fix-curl-error-options
 - Rename CURL_OPTS to CURL_OPTIONS in build.sh

Changes: https://git.openjdk.org/jtreg/pull/238/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=238&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903936
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/238.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/238/head:pull/238

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

From duke at openjdk.org  Tue Jan 21 16:15:08 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 21 Jan 2025 16:15:08 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation [v2]
In-Reply-To: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
Message-ID: <OgzGbZIyRUg__fv9Cy1d9OLWyCcEaHIcDMRTb886GDM=.46528052-3f29-45c5-b5f6-2901196e09cf@github.com>

> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
> 
> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.

Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:

  Update the second year of make/build.sh to 2025

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/238/files
  - new: https://git.openjdk.org/jtreg/pull/238/files/c3fb91a9..14692275

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

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

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

From duke at openjdk.org  Tue Jan 21 16:20:16 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 21 Jan 2025 16:20:16 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation [v3]
In-Reply-To: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
Message-ID: <XrLJFpY-B54G2o2EtktOa9bZ2n28rqqveHqIbbg7stw=.e5c868d0-5579-4944-922c-244d8e4644cc@github.com>

> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
> 
> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.

Oleksii Sylichenko has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Update the second year of make/build.sh to 2025

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/238/files
  - new: https://git.openjdk.org/jtreg/pull/238/files/14692275..a1c638f9

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

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

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

From duke at openjdk.org  Tue Jan 21 16:38:33 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 21 Jan 2025 16:38:33 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation [v4]
In-Reply-To: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
Message-ID: <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>

> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
> 
> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.

Oleksii Sylichenko has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/fix-wget-options-variable' into fix-curl-error-options
 - Rename WGET_OPTS to WGET_OPTIONS in build.sh
   
   Changed variable name WGET_OPTS to WGET_OPTIONS in the documentation block "Some noteworthy control variables" in build.sh.
   
   WGET_OPTIONS is used in the download_using_wget() function in build-support/build-common.sh.

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/238/files
  - new: https://git.openjdk.org/jtreg/pull/238/files/a1c638f9..26d19213

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

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

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

From duke at openjdk.org  Tue Jan 21 16:45:53 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 21 Jan 2025 16:45:53 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation
In-Reply-To: <Yl3tqCu-m1u0y1WgtyXQizG633IcuGPIZ6mhMyaRfqg=.6d22d2eb-c174-4f5c-b586-776e32e39fb7@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
 <Yl3tqCu-m1u0y1WgtyXQizG633IcuGPIZ6mhMyaRfqg=.6d22d2eb-c174-4f5c-b586-776e32e39fb7@github.com>
Message-ID: <9UDjIVkF8er4V1OuAMp3EzoS4FqGzMXRro_EX4YZt7s=.73d5c2f7-3f57-45d6-a3a1-e96e11ade7d9@github.com>

On Tue, 21 Jan 2025 15:47:37 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
>> 
>> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.
>
> Thanks for the contribution @asilichenko!
> 
> - Please update this pull request to also include the changes from #239 and close #239 in favor of this pull request.
> - Please update the title of this pull request to read: `7903936: Update variable names in build.sh documentation` , I created https://bugs.openjdk.org/browse/CODETOOLS-7903936 for this renaming task.
> - Please update the second year in line 4 of `build.sh` from `2024` to `2025`.

@sormuras done

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

PR Comment: https://git.openjdk.org/jtreg/pull/238#issuecomment-2605232550

From cstein at openjdk.org  Tue Jan 21 16:48:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 21 Jan 2025 16:48:51 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation [v4]
In-Reply-To: <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
 <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>
Message-ID: <J5YiejPICC-tMWe6TQqU7qCY3J28nfgvwzDhAxtgBvM=.8763738a-d585-4abc-866e-df5ff356969d@github.com>

On Tue, 21 Jan 2025 16:38:33 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
>> 
>> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.
>
> Oleksii Sylichenko has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/fix-wget-options-variable' into fix-curl-error-options
>  - Rename WGET_OPTS to WGET_OPTIONS in build.sh
>    
>    Changed variable name WGET_OPTS to WGET_OPTIONS in the documentation block "Some noteworthy control variables" in build.sh.
>    
>    WGET_OPTIONS is used in the download_using_wget() function in build-support/build-common.sh.

Okay. Let's wait until a Reviewer also checks off this pull request. Next steps will be called out by the OpenJDK bot...

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

PR Comment: https://git.openjdk.org/jtreg/pull/238#issuecomment-2605242550

From cstein at openjdk.org  Tue Jan 21 16:45:53 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 21 Jan 2025 16:45:53 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation [v4]
In-Reply-To: <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
 <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>
Message-ID: <TXXgM0vl9jNd4M9_y7SQFg7PxV4e-CfYbneoI68e7b8=.e37b847a-8a11-42b5-9b3c-27e5ad9fd22e@github.com>

On Tue, 21 Jan 2025 16:38:33 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
>> 
>> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.
>
> Oleksii Sylichenko has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/fix-wget-options-variable' into fix-curl-error-options
>  - Rename WGET_OPTS to WGET_OPTIONS in build.sh
>    
>    Changed variable name WGET_OPTS to WGET_OPTIONS in the documentation block "Some noteworthy control variables" in build.sh.
>    
>    WGET_OPTIONS is used in the download_using_wget() function in build-support/build-common.sh.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jtreg/pull/238#pullrequestreview-2565183647

From iris at openjdk.org  Tue Jan 21 17:17:53 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 21 Jan 2025 17:17:53 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation [v4]
In-Reply-To: <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
 <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>
Message-ID: <JSnYeGBhc3bsAP6cUjhC8j-nSTRCcZfgRPQIPsbA6Kg=.1093736c-ba1a-4b6d-881c-a028561c8add@github.com>

On Tue, 21 Jan 2025 16:38:33 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
>> 
>> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.
>
> Oleksii Sylichenko has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/fix-wget-options-variable' into fix-curl-error-options
>  - Rename WGET_OPTS to WGET_OPTIONS in build.sh
>    
>    Changed variable name WGET_OPTS to WGET_OPTIONS in the documentation block "Some noteworthy control variables" in build.sh.
>    
>    WGET_OPTIONS is used in the download_using_wget() function in build-support/build-common.sh.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/238#pullrequestreview-2565260015

From duke at openjdk.org  Tue Jan 21 17:31:53 2025
From: duke at openjdk.org (duke)
Date: Tue, 21 Jan 2025 17:31:53 GMT
Subject: RFR: 7903936: Update variable names in build.sh documentation [v4]
In-Reply-To: <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
 <Vm1rh5v3qVVL9kRFvQq_o4e3kUhVYrFop2phXekCUZM=.a0979196-7eea-46ef-9645-76bf06ce1003@github.com>
Message-ID: <KT6fSCmvJ-XoXO9LHnvw2mrlmrJFa1XKDcFy2G8462k=.c772f33e-5868-4a00-8667-30c0e6b38b10@github.com>

On Tue, 21 Jan 2025 16:38:33 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
>> 
>> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.
>
> Oleksii Sylichenko has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/fix-wget-options-variable' into fix-curl-error-options
>  - Rename WGET_OPTS to WGET_OPTIONS in build.sh
>    
>    Changed variable name WGET_OPTS to WGET_OPTIONS in the documentation block "Some noteworthy control variables" in build.sh.
>    
>    WGET_OPTIONS is used in the download_using_wget() function in build-support/build-common.sh.

@asilichenko 
Your change (at version 26d19213b0e4fc933839a78ec9cc09c294ece6b2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jtreg/pull/238#issuecomment-2605343852

From duke at openjdk.org  Tue Jan 21 19:32:53 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 21 Jan 2025 19:32:53 GMT
Subject: Integrated: 7903936: Update variable names in build.sh documentation
In-Reply-To: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
References: <1vS68OrSQxIcL1jqHMuV7isC_MoADbTcupQSH1NVgnk=.ec944759-1cfe-4f48-9d45-5d2667dc2c0e@github.com>
Message-ID: <EyL1MhPko4EHuokv_ppI_jHrjaEaVx8SkWyYbJuNQ6M=.0478e0cc-e8bf-4095-8515-e8ea45d73842@github.com>

On Tue, 7 Jan 2025 16:04:39 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Changed variable name `CURL_OPTS` to `CURL_OPTIONS` in the documentation block "Some noteworthy control variables" in `build.sh`. 
> 
> `CURL_OPTIONS` is used in the `download_using_curl()` function in `build-support/build-common.sh`.

This pull request has now been integrated.

Changeset: 4544d5f4
Author:    asilichenko <a.silichenko at gmail.com>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/4544d5f4bc276ed9f55e49e75941714ad39d130e
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

7903936: Update variable names in build.sh documentation

Reviewed-by: cstein, iris

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

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

From duke at openjdk.org  Fri Jan 24 20:49:34 2025
From: duke at openjdk.org (snake66)
Date: Fri, 24 Jan 2025 20:49:34 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
Message-ID: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>

On FreeBSD we need to use GNU gmake instead of the BSD make program.

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

Commit messages:
 - Defs.gmk: Use proper prefix for binaries on FreeBSD.
 - Defs.gmk: Use GNU grep on FreeBSD
 - Platform.gmk: Add support for FreeBSD as a target.
 - build.sh: Parameterize make binary.

Changes: https://git.openjdk.org/jtreg/pull/237/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=237&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903920
  Stats: 32 lines in 3 files changed: 31 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/237.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/237/head:pull/237

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

From duke at openjdk.org  Fri Jan 24 20:49:35 2025
From: duke at openjdk.org (snake66)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <ZBxOvBT-49Ai693wrOwzD7wEE1LkYa2CvwUytlZbDEo=.86c0e735-4493-4a06-950b-c1e51b8e14a8@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

This work is done on behalf of The FreeBSD Foundation. https://oca.opensource.oracle.com/api/v1/members/public?&search=FreeBSD

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

PR Comment: https://git.openjdk.org/jtreg/pull/237#issuecomment-2543057988

From cstein at openjdk.org  Fri Jan 24 20:49:35 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <ZBxOvBT-49Ai693wrOwzD7wEE1LkYa2CvwUytlZbDEo=.86c0e735-4493-4a06-950b-c1e51b8e14a8@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <ZBxOvBT-49Ai693wrOwzD7wEE1LkYa2CvwUytlZbDEo=.86c0e735-4493-4a06-950b-c1e51b8e14a8@github.com>
Message-ID: <M4j14Mh_dGpmVejIw_PKAZgcmWY9D372f4DEegmwLK8=.39d41871-9e57-415f-9457-b24e5e629323@github.com>

On Sat, 14 Dec 2024 11:03:38 GMT, snake66 <duke at openjdk.org> wrote:

>> On FreeBSD we need to use GNU gmake instead of the BSD make program.
>
> This work is done on behalf of The FreeBSD Foundation. https://oca.opensource.oracle.com/api/v1/members/public?&search=FreeBSD

Thanks for creating the PR, @snake66 - can you please create a JBS issue for this change? Happy to help if needed: https://bugs.openjdk.org/browse/CODETOOLS

@jonathan-gibbons wrote in https://github.com/openjdk/jtreg/commit/8a66b3b8f8f844f442a74f1d651cfc03f9231bb7#commitcomment-150335752
> Stylistically, it would be more in keeping to determine the absolute path on FreeBSD, instead of just relying on $PATH. You can do this either by checking the OS name or by checking in standard well-known places in order to determine an absolute path. See examples of other variables nearby.

Seems like this change avoids relying on `$PATH`. Do you also consider doing something similar for `zip` and `unzip` in this change set?

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

PR Comment: https://git.openjdk.org/jtreg/pull/237#issuecomment-2543058251

From duke at openjdk.org  Fri Jan 24 20:49:35 2025
From: duke at openjdk.org (snake66)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <ZBxOvBT-49Ai693wrOwzD7wEE1LkYa2CvwUytlZbDEo=.86c0e735-4493-4a06-950b-c1e51b8e14a8@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <ZBxOvBT-49Ai693wrOwzD7wEE1LkYa2CvwUytlZbDEo=.86c0e735-4493-4a06-950b-c1e51b8e14a8@github.com>
Message-ID: <l22t_rQ5QFt-suRVT5y3TNkYH7Y-aBEnGSAmfjNhL2w=.2d1a1837-0a80-402e-a2a7-73bcc07392ee@github.com>

On Sat, 14 Dec 2024 11:03:38 GMT, snake66 <duke at openjdk.org> wrote:

>> On FreeBSD we need to use GNU gmake instead of the BSD make program.
>
> This work is done on behalf of The FreeBSD Foundation. https://oca.opensource.oracle.com/api/v1/members/public?&search=FreeBSD

> Thanks for creating the PR, @snake66 - can you please create a JBS issue for this change? Happy to help if needed: https://bugs.openjdk.org/browse/CODETOOLS

Thanks, I'm not sure if I have access to create issues? The credentials for the oracle account did not work.

> Seems like this change avoids relying on `$PATH`. Do you also consider doing something similar for `zip` and `unzip` in this change set?

Yes, I was unsure if those changes would pass, so I'll follow your recommendations.

Do you want me to include the rest of the FreeBSD related changes to this PR, or is it preferable to do separate PR's for each change?

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

PR Comment: https://git.openjdk.org/jtreg/pull/237#issuecomment-2543305580

From cstein at openjdk.org  Fri Jan 24 20:49:35 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <fOMQZuxTlQUPSsp_4qCx_gXMez9Ei5JythbQvOSFwTk=.2a6306ba-1d8e-41ac-b985-2120a0e822a7@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

Created https://bugs.openjdk.org/browse/CODETOOLS-7903920 to track this improvement to `jtreg`'s build system "in one go".

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

PR Comment: https://git.openjdk.org/jtreg/pull/237#issuecomment-2556895200

From duke at openjdk.org  Fri Jan 24 20:49:35 2025
From: duke at openjdk.org (Ed Maste)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <k_NzgznmuHaaA_iZHcX0JagrRrGiASlqkVv9NYWco0g=.8c78afe0-f646-4f05-8d9f-8a60fe675519@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

Bump PR as it seems bridgekeeper did not notice newly pushed commits

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

PR Comment: https://git.openjdk.org/jtreg/pull/237#issuecomment-2598952728

From ihse at openjdk.org  Fri Jan 24 20:49:35 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

make/Defs.gmk line 145:

> 143: FIND	= /usr/bin/find
> 144: ifeq ($(SYSTEM_UNAME), FreeBSD)
> 145: GREP  := $(shell if [ -r /usr/local/bin/ggrep ]; then \

Maybe consider using ``which ggrep`` instead?

make/Defs.gmk line 186:

> 184: TOUCH 	= /usr/bin/touch
> 185: ifeq ($(SYSTEM_UNAME), FreeBSD)
> 186: UNZIP	= /usr/local/bin/unzip

Once again, maybe use `which` instead? Unless you have two installations of unzip, and the one in /usr/bin is broken in some way. Then you might need to check for brokenness instead.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1923644697
PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1923646156

From duke at openjdk.org  Fri Jan 24 20:49:35 2025
From: duke at openjdk.org (snake66)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
Message-ID: <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>

On Tue, 21 Jan 2025 12:30:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> On FreeBSD we need to use GNU gmake instead of the BSD make program.
>
> make/Defs.gmk line 145:
> 
>> 143: FIND	= /usr/bin/find
>> 144: ifeq ($(SYSTEM_UNAME), FreeBSD)
>> 145: GREP  := $(shell if [ -r /usr/local/bin/ggrep ]; then \
> 
> Maybe consider using ``which ggrep`` instead?

Wouldn't this pretty much just be the same as just not specifying the path at all, and let the shell find it in $PATH? Which was [one of the complaints](https://github.com/openjdk/jtreg/pull/237#issuecomment-2543058251) against my first patch.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1927529089

From ihse at openjdk.org  Fri Jan 24 20:49:35 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
 <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
Message-ID: <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>

On Thu, 23 Jan 2025 18:52:57 GMT, snake66 <duke at openjdk.org> wrote:

>> make/Defs.gmk line 145:
>> 
>>> 143: FIND	= /usr/bin/find
>>> 144: ifeq ($(SYSTEM_UNAME), FreeBSD)
>>> 145: GREP  := $(shell if [ -r /usr/local/bin/ggrep ]; then \
>> 
>> Maybe consider using ``which ggrep`` instead?
>
> Wouldn't this pretty much just be the same as just not specifying the path at all, and let the shell find it in $PATH? Which was [one of the complaints](https://github.com/openjdk/jtreg/pull/237#issuecomment-2543058251) against my first patch.

Okay, people have apparently varying opinions on this. :) Don't want to put you in a "damned if you do, damned if you don't" situation, so just ignore my comment and go with your solution.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1927605137

From duke at openjdk.org  Fri Jan 24 20:49:35 2025
From: duke at openjdk.org (snake66)
Date: Fri, 24 Jan 2025 20:49:35 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
 <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
 <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>
Message-ID: <bZyxSb9MZEN_40G5LY4vckYe8Lq4vvO3NOlqfUjOvIo=.6fd52af2-9555-47de-a7be-e61c441e5d7f@github.com>

On Thu, 23 Jan 2025 19:55:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Wouldn't this pretty much just be the same as just not specifying the path at all, and let the shell find it in $PATH? Which was [one of the complaints](https://github.com/openjdk/jtreg/pull/237#issuecomment-2543058251) against my first patch.
>
> Okay, people have apparently varying opinions on this. :) Don't want to put you in a "damned if you do, damned if you don't" situation, so just ignore my comment and go with your solution.

I don't have any strong opinions about this, but for FreeBSD's part it would actually be slightly better to let the shell find the binaries in $PATH. But it's not important for my progress now, so I figured I'd deal with it if it comes up :)

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1927617050

From jjg at openjdk.org  Fri Jan 24 23:04:01 2025
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 24 Jan 2025 23:04:01 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <bZyxSb9MZEN_40G5LY4vckYe8Lq4vvO3NOlqfUjOvIo=.6fd52af2-9555-47de-a7be-e61c441e5d7f@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
 <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
 <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>
 <bZyxSb9MZEN_40G5LY4vckYe8Lq4vvO3NOlqfUjOvIo=.6fd52af2-9555-47de-a7be-e61c441e5d7f@github.com>
Message-ID: <28TZAhza2PZTdS6QTMeuJWIVXYduO60W9KaOdoOoGgE=.1ce726bb-c0b0-4f72-bcb6-fc5599dd5b9d@github.com>

On Thu, 23 Jan 2025 20:06:27 GMT, snake66 <duke at openjdk.org> wrote:

>> Okay, people have apparently varying opinions on this. :) Don't want to put you in a "damned if you do, damned if you don't" situation, so just ignore my comment and go with your solution.
>
> I don't have any strong opinions about this, but for FreeBSD's part it would actually be slightly better to let the shell find the binaries in $PATH. But it's not important for my progress now, so I figured I'd deal with it if it comes up :)

Maybe the concern is becoming obsolete, but the general design focus of this and similar scripts was to lock down everything, and avoid any variation that might occur as a result of individuals setting non-standard values for PATH and similar path-related variables -- CLASSPATH anyone?

But, a reasonable compromise would be to limit the use of `which` to this file (`Defs.gmk`) and maybe to within suitable `ifeq ($(SYSTEM_UNAME), FreeBSD)` constructs.

That all being said, I would defer to the expertise and style-advice of folk like @magicus on the Build team,  but with some amount of caveat for overall style consistency, as much as is reasonable.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1929341033

From ihse at openjdk.org  Sat Jan 25 20:40:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 25 Jan 2025 20:40:58 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <28TZAhza2PZTdS6QTMeuJWIVXYduO60W9KaOdoOoGgE=.1ce726bb-c0b0-4f72-bcb6-fc5599dd5b9d@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
 <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
 <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>
 <bZyxSb9MZEN_40G5LY4vckYe8Lq4vvO3NOlqfUjOvIo=.6fd52af2-9555-47de-a7be-e61c441e5d7f@github.com>
 <28TZAhza2PZTdS6QTMeuJWIVXYduO60W9KaOdoOoGgE=.1ce726bb-c0b0-4f72-bcb6-fc5599dd5b9d@github.com>
Message-ID: <rv5HRqlmrxoBqWoNiE6iqOlwtDV6O2vhB14rpTUbnLs=.9ed7b3eb-5de4-493e-b907-6bd2e0bd6c17@github.com>

On Fri, 24 Jan 2025 23:01:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> I don't have any strong opinions about this, but for FreeBSD's part it would actually be slightly better to let the shell find the binaries in $PATH. But it's not important for my progress now, so I figured I'd deal with it if it comes up :)
>
> Maybe the concern is becoming obsolete, but the general design focus of this and similar scripts was to lock down everything, and avoid any variation that might occur as a result of individuals setting non-standard values for PATH and similar path-related variables -- CLASSPATH anyone?
> 
> But, a reasonable compromise would be to limit the use of `which` to this file (`Defs.gmk`) and maybe to within suitable `ifeq ($(SYSTEM_UNAME), FreeBSD)` constructs.
> 
> That all being said, I would defer to the expertise and style-advice of folk like @magicus on the Build team,  but with some amount of caveat for overall style consistency, as much as is reasonable.

If the path is hardcoded as e.g. `/usr/bin/foo`, I tend to agree with you. That means that an official system tool is needed and confirmed working. However, hard-coding `/usr/local/bin/foo` is another matter altogether. It means there is no standard system tool that is working, and we presume the user has installed a "correct" tool locally.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1929606154

From ihse at openjdk.org  Sat Jan 25 20:40:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 25 Jan 2025 20:40:58 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <rv5HRqlmrxoBqWoNiE6iqOlwtDV6O2vhB14rpTUbnLs=.9ed7b3eb-5de4-493e-b907-6bd2e0bd6c17@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
 <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
 <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>
 <bZyxSb9MZEN_40G5LY4vckYe8Lq4vvO3NOlqfUjOvIo=.6fd52af2-9555-47de-a7be-e61c441e5d7f@github.com>
 <28TZAhza2PZTdS6QTMeuJWIVXYduO60W9KaOdoOoGgE=.1ce726bb-c0b0-4f72-bcb6-fc5599dd5b9d@github.com>
 <rv5HRqlmrxoBqWoNiE6iqOlwtDV6O2vhB14rpTUbnLs=.9ed7b3eb-5de4-493e-b907-6bd2e0bd6c17@github.com>
Message-ID: <MXfmzFK3jXo7kC_Kthux8c18Nqvj58uZEVj-Hgn3VmI=.4a63f3bd-c1e7-4c29-9545-deb2c2ae944e@github.com>

On Sat, 25 Jan 2025 20:37:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Maybe the concern is becoming obsolete, but the general design focus of this and similar scripts was to lock down everything, and avoid any variation that might occur as a result of individuals setting non-standard values for PATH and similar path-related variables -- CLASSPATH anyone?
>> 
>> But, a reasonable compromise would be to limit the use of `which` to this file (`Defs.gmk`) and maybe to within suitable `ifeq ($(SYSTEM_UNAME), FreeBSD)` constructs.
>> 
>> That all being said, I would defer to the expertise and style-advice of folk like @magicus on the Build team,  but with some amount of caveat for overall style consistency, as much as is reasonable.
>
> If the path is hardcoded as e.g. `/usr/bin/foo`, I tend to agree with you. That means that an official system tool is needed and confirmed working. However, hard-coding `/usr/local/bin/foo` is another matter altogether. It means there is no standard system tool that is working, and we presume the user has installed a "correct" tool locally.

If the path is hardcoded as e.g. `/usr/bin/foo`, I tend to agree with you. That means that an official system tool is needed and confirmed working. However, hard-coding `/usr/local/bin/foo` is another matter altogether. It means there is no standard system tool that is working, and we presume the user has installed a "correct" tool locally.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1929606160

From ihse at openjdk.org  Sat Jan 25 20:40:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 25 Jan 2025 20:40:58 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <MXfmzFK3jXo7kC_Kthux8c18Nqvj58uZEVj-Hgn3VmI=.4a63f3bd-c1e7-4c29-9545-deb2c2ae944e@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
 <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
 <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>
 <bZyxSb9MZEN_40G5LY4vckYe8Lq4vvO3NOlqfUjOvIo=.6fd52af2-9555-47de-a7be-e61c441e5d7f@github.com>
 <28TZAhza2PZTdS6QTMeuJWIVXYduO60W9KaOdoOoGgE=.1ce726bb-c0b0-4f72-bcb6-fc5599dd5b9d@github.com>
 <rv5HRqlmrxoBqWoNiE6iqOlwtDV6O2vhB14rpTUbnLs=.9ed7b3eb-5de4-493e-b907-6bd2e0bd6c17@github.com>
 <MXfmzFK3jXo7kC_Kthux8c18Nqvj58uZEVj-Hgn3VmI=.4a63f3bd-c1e7-4c29-9545-deb2c2ae944e@github.com>
Message-ID: <4DPLKwJvuw9WsAZEomgkPznhXRkMoAqKmYR2WNFWSSA=.601ff2e8-3b03-4a3e-a11d-ac1d118e5437@github.com>

On Sat, 25 Jan 2025 20:37:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> If the path is hardcoded as e.g. `/usr/bin/foo`, I tend to agree with you. That means that an official system tool is needed and confirmed working. However, hard-coding `/usr/local/bin/foo` is another matter altogether. It means there is no standard system tool that is working, and we presume the user has installed a "correct" tool locally.
>
> If the path is hardcoded as e.g. `/usr/bin/foo`, I tend to agree with you. That means that an official system tool is needed and confirmed working. However, hard-coding `/usr/local/bin/foo` is another matter altogether. It means there is no standard system tool that is working, and we presume the user has installed a "correct" tool locally.

(uness BSD does thing different in this regard and install all user-installed packages in /usr/local?)

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1929606219

From duke at openjdk.org  Sun Jan 26 08:30:57 2025
From: duke at openjdk.org (snake66)
Date: Sun, 26 Jan 2025 08:30:57 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <4DPLKwJvuw9WsAZEomgkPznhXRkMoAqKmYR2WNFWSSA=.601ff2e8-3b03-4a3e-a11d-ac1d118e5437@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
 <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
 <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>
 <bZyxSb9MZEN_40G5LY4vckYe8Lq4vvO3NOlqfUjOvIo=.6fd52af2-9555-47de-a7be-e61c441e5d7f@github.com>
 <28TZAhza2PZTdS6QTMeuJWIVXYduO60W9KaOdoOoGgE=.1ce726bb-c0b0-4f72-bcb6-fc5599dd5b9d@github.com>
 <rv5HRqlmrxoBqWoNiE6iqOlwtDV6O2vhB14rpTUbnLs=.9ed7b3eb-5de4-493e-b907-6bd2e0bd6c17@github.com>
 <MXfmzFK3jXo7kC_Kthux8c18Nqvj58uZEVj-Hgn3VmI=.4a63f3bd-c1e7-4c29-9545-deb2c2ae944e@github.com>
 <4DPLKwJvuw9WsAZEomgkPznhXRkMoAqKmYR2WNFWSSA=.601ff2e8-3b03-4a3e-a11d-ac1d118e5437@github.com>
Message-ID: <MR07QEc0B8NNFX1cgecaG1TXWhPk5NKiebTxY01QZ9M=.31e36ed9-96c5-4ae8-ae63-45ef09eb7de0@github.com>

On Sat, 25 Jan 2025 20:38:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> (uness BSD does thing different in this regard and install all user-installed packages in /usr/local?)

Yep, that's how FreeBSD does things. (Technically the prefix can be something different than /usr/local, but that's the default.)

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1929691653

From ihse at openjdk.org  Sun Jan 26 18:20:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 26 Jan 2025 18:20:58 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <LDwTJ0GslE2TiPd6qnUbxhgFEhcw2LI122Lic5bSiZc=.fb6d114b-3b9f-40e7-9236-dea209a2b511@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

Looks good to me. (But I'm no Reviewer)

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

Marked as reviewed by ihse (Author).

PR Review: https://git.openjdk.org/jtreg/pull/237#pullrequestreview-2574354224

From ihse at openjdk.org  Sun Jan 26 18:20:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 26 Jan 2025 18:20:58 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <MR07QEc0B8NNFX1cgecaG1TXWhPk5NKiebTxY01QZ9M=.31e36ed9-96c5-4ae8-ae63-45ef09eb7de0@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <3TuoXZhUAehVknN_tcEAl8ioiXFVyFjXvZ6lqcfworg=.e4b3250f-942c-4b4f-856a-995216a74b0a@github.com>
 <TLyqvTn1ys_VuQFZuHK3CcggriSbfGTZCwCc4k_ZO5o=.478537c6-7424-4efd-a8f7-daee5202a7c8@github.com>
 <JztcS-7nR0D1Iv7ug1ZgeM8AqQTxoJzpalcJg2flcjQ=.54e23877-0760-4e5c-868c-a6921da74b7b@github.com>
 <bZyxSb9MZEN_40G5LY4vckYe8Lq4vvO3NOlqfUjOvIo=.6fd52af2-9555-47de-a7be-e61c441e5d7f@github.com>
 <28TZAhza2PZTdS6QTMeuJWIVXYduO60W9KaOdoOoGgE=.1ce726bb-c0b0-4f72-bcb6-fc5599dd5b9d@github.com>
 <rv5HRqlmrxoBqWoNiE6iqOlwtDV6O2vhB14rpTUbnLs=.9ed7b3eb-5de4-493e-b907-6bd2e0bd6c17@github.com>
 <MXfmzFK3jXo7kC_Kthux8c18Nqvj58uZEVj-Hgn3VmI=.4a63f3bd-c1e7-4c29-9545-deb2c2ae944e@github.com>
 <4DPLKwJvuw9WsAZEomgkPznhXRkMoAqKmYR2WNFWSSA=.601ff2e8-3b03-4a3e-a11d-ac1d118e5437@github.com>
 <MR07QEc0B8NNFX1cgecaG1TXWhPk5NKiebTxY01QZ9M=.31e36ed9-96c5-4ae8-ae63-45ef09eb7de0@github.com>
Message-ID: <RAV62IOWk-BSj4F-ckDWx7fWr7IRaMuydNGaTo0ZEfs=.156d93bb-4f9e-4b6e-a4d7-ac1c47c6b75d@github.com>

On Sun, 26 Jan 2025 08:28:05 GMT, snake66 <duke at openjdk.org> wrote:

>> (uness BSD does thing different in this regard and install all user-installed packages in /usr/local?)
>
>> (uness BSD does thing different in this regard and install all user-installed packages in /usr/local?)
> 
> Yep, that's how FreeBSD does things. (Technically the prefix can be something different than /usr/local, but that's the default.)

Ok, in that case this makes totally sense.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/237#discussion_r1929836976

From lujaniuk at openjdk.org  Mon Jan 27 10:01:45 2025
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Mon, 27 Jan 2025 10:01:45 GMT
Subject: RFR: 7903935: --verify-exclude existence check misses tests with
 failing requires
Message-ID: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>

7903935: --verify-exclude existence check misses tests with failing requires

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

Commit messages:
 - Update comment
 - 7903935 --verify-exclude existence check misses tests with failing requires

Changes: https://git.openjdk.org/jtreg/pull/243/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=243&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903935
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/243.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/243/head:pull/243

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

From lujaniuk at openjdk.org  Mon Jan 27 10:18:13 2025
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Mon, 27 Jan 2025 10:18:13 GMT
Subject: RFR: 7903935: --verify-exclude existence check misses tests with
 failing requires
In-Reply-To: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>
References: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>
Message-ID: <QbgcD0zjD2PtsfbCgd-G-8cXzCV3UuBG44uN2HoYYBM=.2a1dfa93-bcd9-48e3-a18d-8017e73816dc@github.com>

On Tue, 21 Jan 2025 14:20:25 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> The current implementation relies on
>   getResultsIterator
> which in turn calls into
>   TestResultTable.getIterator(filters)
> passing into jtharness. That seems to currently filter out tests that don't meet the local "requires" criteria. Thus we fail to collect all "existing" tests in to a set to compare with.
> 
> The fix seems to be to explicitly pass an empty list of filters into
>   TestResultTable.getIterator(filters)
> as this will make
>   TRT_Iterator.wouldAccept()
> accept every test.

As a way to test these changes on real-world data, I ran against the OpenJDK problemlist files. The following lists how many tests in each were listed as problematic:

test/lib-test/ProblemList.txt: 0
test/jaxp/ProblemList.txt: 0
test/docs/ProblemList.txt: 0
test/hotspot/jtreg/ProblemList-AotJdk.txt: 1
test/hotspot/jtreg/ProblemList.txt: 3
test/hotspot/jtreg/ProblemList-Virtual.txt: 0
test/hotspot/jtreg/ProblemList-Xcomp.txt: 0
test/hotspot/jtreg/ProblemList-zgc.txt: 14
test/jdk/ProblemList-AotJdk.txt: 0
test/jdk/ProblemList-zgc.txt: 0
test/jdk/ProblemList-shenandoah.txt: 0
test/jdk/ProblemList-Virtual.txt: 4
test/jdk/ProblemList.txt: 8
test/jdk/ProblemList-Xcomp.txt: 0
test/langtools/ProblemList.txt: 0

After a manual look at `test/hotspot/jtreg/ProblemList-zgc.txt`, it does look like it references a lot of tests that don't exist. These were:

serviceability/sa/ClhsdbFindPC.java#apa                       8307393   generic-all
serviceability/sa/ClhsdbLauncher.java                         8307393   generic-all
serviceability/sa/ClhsdbPmap.java                             8307393   generic-all
serviceability/sa/ClhsdbScanOops.java                         8307393   generic-all
serviceability/sa/LingeredAppSysProps.java                    8307393   generic-all
serviceability/sa/LingeredAppWithDefaultMethods.java          8307393   generic-all
serviceability/sa/LingeredAppWithEnum.java                    8307393   generic-all
serviceability/sa/LingeredAppWithInterface.java               8307393   generic-all
serviceability/sa/LingeredAppWithInvokeDynamic.java           8307393   generic-all
serviceability/sa/LingeredAppWithLock.java                    8307393   generic-all
serviceability/sa/LingeredAppWithNativeMethod.java            8307393   generic-all
serviceability/sa/LingeredAppWithRecComputation.java          8307393   generic-all
serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java      8307393   generic-all
serviceability/sa/sadebugd/DebugdUtils.java                   8307393   generic-all

Indeed, manual sampling reveals these lines are invalid, e.g. because `ClhsdbFindPC.java` does not have a test with id `apa`, or because `serviceability/sa/LingeredAppWithInterface.java` is not a jtreg test at all (no `@test` comment).

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

PR Comment: https://git.openjdk.org/jtreg/pull/243#issuecomment-2615342921

From cstein at openjdk.org  Mon Jan 27 11:35:03 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 27 Jan 2025 11:35:03 GMT
Subject: RFR: 7903931: Add "jtreg.ttf" property to filter tests based on
 test thread factory value
In-Reply-To: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
Message-ID: <FS7IYiDRfr9ZNlmKvnRXGk6TDi4Rhm1tOPIC-RnPOec=.5c71cb0e-9bf2-4c6b-8f45-4d1dc4261ad9@github.com>

On Tue, 14 Jan 2025 04:06:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
> 
> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
> 
> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
> 
> The only jtreg knows if -testThreadFactory is set so it should set corresponding property

The namespace `jtreg.` is not used in `RegressionContext` yet, but it makes sense to introduce it here.

Is `ttf` a good abbreviation for `test thread factory` though? Would `jtreg.testThreadFactory` be too long in filter expressions?

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

PR Comment: https://git.openjdk.org/jtreg/pull/242#issuecomment-2615513047

From cstein at openjdk.org  Mon Jan 27 12:17:20 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 27 Jan 2025 12:17:20 GMT
Subject: RFR: 7903940: Remove problematic `LIBRARY.properties` implementation
Message-ID: <9INJ92ywHjz-Hllnn2wt-SuQtecle3YztM0SEdEmBHQ=.12bae73e-e5aa-45f3-8058-33c295c0b910@github.com>

Please review this change to remove the `LIBRARY.properties` implementation from `jtreg`

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

Commit messages:
 - 7903940: Remove problematic `LIBRARY.properties` implementation

Changes: https://git.openjdk.org/jtreg/pull/244/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=244&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903940
  Stats: 407 lines in 19 files changed: 3 ins; 398 del; 6 mod
  Patch: https://git.openjdk.org/jtreg/pull/244.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/244/head:pull/244

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

From cstein at openjdk.org  Mon Jan 27 14:08:15 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 27 Jan 2025 14:08:15 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <B8Vh5hvJ88kaQ3-dQPxCkm8NbBEFr6kGP9OiixQD784=.6a704e86-9d9f-47e3-b156-2948763a117d@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

@jonathan-gibbons Do you have any additional comments or changes to suggest/request? If not, a final **R**eview of this PR would be awesome. ?

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

PR Comment: https://git.openjdk.org/jtreg/pull/237#issuecomment-2615850120

From lmesnik at openjdk.org  Mon Jan 27 16:33:09 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 27 Jan 2025 16:33:09 GMT
Subject: RFR: 7903931: Add "jtreg.ttf" property to filter tests based on
 test thread factory value
In-Reply-To: <FS7IYiDRfr9ZNlmKvnRXGk6TDi4Rhm1tOPIC-RnPOec=.5c71cb0e-9bf2-4c6b-8f45-4d1dc4261ad9@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
 <FS7IYiDRfr9ZNlmKvnRXGk6TDi4Rhm1tOPIC-RnPOec=.5c71cb0e-9bf2-4c6b-8f45-4d1dc4261ad9@github.com>
Message-ID: <0r93qib7Fkgq8jtDvoNAN1mZNmqeQNzDq76zfvgG9lo=.f6275d15-cc43-4839-8cde-4ea5d753790d@github.com>

On Mon, 27 Jan 2025 11:32:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> The namespace `jtreg.` is not used in `RegressionContext` yet, but it makes sense to introduce it here.
> 
> Is `ttf` a good abbreviation for `test thread factory` though? Would `jtreg.testThreadFactory` be too long in filter expressions?

I think `jtreg.ttf` is good enough, but might be becasue I know the context. If you feel that for all jtreg users `jtreg.testThreadFactory`, I am fine with this.

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

PR Comment: https://git.openjdk.org/jtreg/pull/242#issuecomment-2616294135

From jjg at openjdk.org  Mon Jan 27 16:47:00 2025
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Jan 2025 16:47:00 GMT
Subject: RFR: 7903931: Add "jtreg.ttf" property to filter tests based on
 test thread factory value
In-Reply-To: <0r93qib7Fkgq8jtDvoNAN1mZNmqeQNzDq76zfvgG9lo=.f6275d15-cc43-4839-8cde-4ea5d753790d@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
 <FS7IYiDRfr9ZNlmKvnRXGk6TDi4Rhm1tOPIC-RnPOec=.5c71cb0e-9bf2-4c6b-8f45-4d1dc4261ad9@github.com>
 <0r93qib7Fkgq8jtDvoNAN1mZNmqeQNzDq76zfvgG9lo=.f6275d15-cc43-4839-8cde-4ea5d753790d@github.com>
Message-ID: <KD5RQBKxrLHRTjn73za8KhWTbC1bRqENXmbLfcaYB9w=.85f35d4b-74a8-436c-9869-34eca12241d7@github.com>

On Mon, 27 Jan 2025 16:30:58 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> > The namespace `jtreg.` is not used in `RegressionContext` yet, but it makes sense to introduce it here.
> > Is `ttf` a good abbreviation for `test thread factory` though? Would `jtreg.testThreadFactory` be too long in filter expressions?
> 
> I think `jtreg.ttf` is good enough, but might be becasue I know the context. If you feel that for all jtreg users `jtreg.testThreadFactory`, I am fine with this.

For the long term, clarity is better than cryptic brevity.

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

PR Comment: https://git.openjdk.org/jtreg/pull/242#issuecomment-2616330427

From cstein at openjdk.org  Tue Jan 28 08:30:01 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 28 Jan 2025 08:30:01 GMT
Subject: RFR: 7903931: Add "jtreg.ttf" property to filter tests based on
 test thread factory value
In-Reply-To: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
Message-ID: <jlkNmsxhsO2ogxpBkyRnq3HaC8bH9MfssosDMm9CEI0=.840dcbc7-5caa-4adb-9011-3d39e63f197e@github.com>

On Tue, 14 Jan 2025 04:06:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
> 
> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
> 
> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
> 
> The only jtreg knows if -testThreadFactory is set so it should set corresponding property

What about re-using the `test.` namespace used by `jtreg` for [system properties](https://openjdk.org/jtreg/tag-spec.html#testvars)? Meaning, we'd call this property introduced here:
- `test.threadFactory`

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

PR Comment: https://git.openjdk.org/jtreg/pull/242#issuecomment-2618235168

From jlahoda at openjdk.org  Tue Jan 28 14:27:01 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 28 Jan 2025 14:27:01 GMT
Subject: RFR: 7903940: Remove problematic `LIBRARY.properties`
 implementation
In-Reply-To: <9INJ92ywHjz-Hllnn2wt-SuQtecle3YztM0SEdEmBHQ=.12bae73e-e5aa-45f3-8058-33c295c0b910@github.com>
References: <9INJ92ywHjz-Hllnn2wt-SuQtecle3YztM0SEdEmBHQ=.12bae73e-e5aa-45f3-8058-33c295c0b910@github.com>
Message-ID: <_M6OreoaLZ2JCgkZ7lwkS9h_7fAk8jmd10FhCo6F2TU=.bbc22e86-15fa-48a5-a475-2c1efbde8e19@github.com>

On Mon, 27 Jan 2025 12:12:26 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to remove the `LIBRARY.properties` implementation from `jtreg`

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Lead).

PR Review: https://git.openjdk.org/jtreg/pull/244#pullrequestreview-2578413937

From rriggs at openjdk.org  Tue Jan 28 14:50:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Jan 2025 14:50:00 GMT
Subject: RFR: 7903940: Remove problematic `LIBRARY.properties`
 implementation
In-Reply-To: <9INJ92ywHjz-Hllnn2wt-SuQtecle3YztM0SEdEmBHQ=.12bae73e-e5aa-45f3-8058-33c295c0b910@github.com>
References: <9INJ92ywHjz-Hllnn2wt-SuQtecle3YztM0SEdEmBHQ=.12bae73e-e5aa-45f3-8058-33c295c0b910@github.com>
Message-ID: <3ks_qOAhren58Xy_k1IenCemwsmh0R-ix5k78Hptfyw=.5e1d2e3f-c9f4-4b23-b610-1b3ea4f1fd7e@github.com>

On Mon, 27 Jan 2025 12:12:26 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to remove the `LIBRARY.properties` implementation from `jtreg`

Not a Reviewer, but looks ok to me.

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

Marked as reviewed by rriggs (no project role).

PR Review: https://git.openjdk.org/jtreg/pull/244#pullrequestreview-2578493672

From cstein at openjdk.org  Tue Jan 28 15:48:06 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 28 Jan 2025 15:48:06 GMT
Subject: Integrated: 7903940: Remove problematic `LIBRARY.properties`
 implementation
In-Reply-To: <9INJ92ywHjz-Hllnn2wt-SuQtecle3YztM0SEdEmBHQ=.12bae73e-e5aa-45f3-8058-33c295c0b910@github.com>
References: <9INJ92ywHjz-Hllnn2wt-SuQtecle3YztM0SEdEmBHQ=.12bae73e-e5aa-45f3-8058-33c295c0b910@github.com>
Message-ID: <UGztvme1YS8kdthtND6Pv_Ex-_FklUrbVKReiY4Bw9k=.187e4fdc-9ed6-4fd3-b888-907bba513bd9@github.com>

On Mon, 27 Jan 2025 12:12:26 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to remove the `LIBRARY.properties` implementation from `jtreg`

This pull request has now been integrated.

Changeset: 7dcd0bcf
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/7dcd0bcfd64b2a9f57d10af2c266b1fb8ea338df
Stats:     407 lines in 19 files changed: 3 ins; 398 del; 6 mod

7903940: Remove problematic `LIBRARY.properties` implementation

Reviewed-by: jlahoda, rriggs

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

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

From lmesnik at openjdk.org  Tue Jan 28 16:18:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 Jan 2025 16:18:02 GMT
Subject: RFR: 7903931: Add "jtreg.ttf" property to filter tests based on
 test thread factory value
In-Reply-To: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
Message-ID: <ToVWJRQUrmSWX9xnssWctDtLk487IA2oYNVPRYybp2U=.77d76e2a-3e79-471d-9412-36c0ed962ed3@github.com>

On Tue, 14 Jan 2025 04:06:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
> 
> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
> 
> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
> 
> The only jtreg knows if -testThreadFactory is set so it should set corresponding property

I'm fine with using test namespace.
Might be
- test.thread.factory
then?

It is the name of property used by test to check thread factory inside of test.
Leonid

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

PR Comment: https://git.openjdk.org/jtreg/pull/242#issuecomment-2619446651

From cstein at openjdk.org  Tue Jan 28 16:18:02 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 28 Jan 2025 16:18:02 GMT
Subject: RFR: 7903931: Add "jtreg.ttf" property to filter tests based on
 test thread factory value
In-Reply-To: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
Message-ID: <8omJZzQVKS_wTiH0ZYv7nL0KVTScxnzNe1hYZ1VaRQM=.2e0a6aec-5c06-43a6-91d2-f4be5bafcb9e@github.com>

On Tue, 14 Jan 2025 04:06:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
> 
> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
> 
> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
> 
> The only jtreg knows if -testThreadFactory is set so it should set corresponding property

We have a winner! `test.thread.factory`

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

PR Comment: https://git.openjdk.org/jtreg/pull/242#issuecomment-2619453545

From lmesnik at openjdk.org  Tue Jan 28 16:46:20 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 Jan 2025 16:46:20 GMT
Subject: RFR: 7903931: Add "test.thread.factory" property to filter tests
 based on test thread factory value [v2]
In-Reply-To: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
Message-ID: <wCLLSsKffjiqZkKOiK72w7GTIKcDUtSop1GLiEZF3oM=.2402108f-3ff9-4bac-80e7-4e89989b25fd@github.com>

> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
> 
> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
> 
> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
> 
> The only jtreg knows if -testThreadFactory is set so it should set corresponding property

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

  test.thread.factory is set

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/242/files
  - new: https://git.openjdk.org/jtreg/pull/242/files/7b9299c0..7cbb70ad

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

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

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

From lmesnik at openjdk.org  Tue Jan 28 17:47:33 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 Jan 2025 17:47:33 GMT
Subject: RFR: 7903931: Add "test.thread.factory" property to filter tests
 based on test thread factory value [v3]
In-Reply-To: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
Message-ID: <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>

> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
> 
> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
> 
> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
> 
> The only jtreg knows if -testThreadFactory is set so it should set corresponding property

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

  test.thread.factory is not a property for tag spec

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/242/files
  - new: https://git.openjdk.org/jtreg/pull/242/files/7cbb70ad..338694bc

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

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

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

From jlahoda at openjdk.org  Wed Jan 29 18:44:01 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 29 Jan 2025 18:44:01 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <TRdW8VRf_uvBYvTr05adEiLol4m0pnCOTWb9WFqc808=.17d72b1f-62a9-4c8d-987f-01dd3d312381@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

Although I am not really an expert, but since @magicus approved, looks sensible to me.

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

Marked as reviewed by jlahoda (Lead).

PR Review: https://git.openjdk.org/jtreg/pull/237#pullrequestreview-2581911771

From jvernee at openjdk.org  Wed Jan 29 19:15:13 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Jan 2025 19:15:13 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v2]
In-Reply-To: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
Message-ID: <bQwAHArOV47JdvykdsibgP2UOrox7xelZtN81LdKSnk=.640b3850-4e0a-4da3-a474-e5e5d3879ef6@github.com>

> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
> 
> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
> 
> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.

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

  Use qualified class name, for the sake of nested test classes

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/240/files
  - new: https://git.openjdk.org/jtreg/pull/240/files/08562497..d9e8947a

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

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

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

From duke at openjdk.org  Thu Jan 30 07:33:59 2025
From: duke at openjdk.org (snake66)
Date: Thu, 30 Jan 2025 07:33:59 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <TRdW8VRf_uvBYvTr05adEiLol4m0pnCOTWb9WFqc808=.17d72b1f-62a9-4c8d-987f-01dd3d312381@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
 <TRdW8VRf_uvBYvTr05adEiLol4m0pnCOTWb9WFqc808=.17d72b1f-62a9-4c8d-987f-01dd3d312381@github.com>
Message-ID: <xvSGkWrsCe0U_1IROR3z0tEacjgdJQCTo8q2PldwbPo=.37cee65a-788e-42c4-b3c3-dc7c3c24dc6b@github.com>

On Wed, 29 Jan 2025 18:41:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> On FreeBSD we need to use GNU gmake instead of the BSD make program.
>
> Although I am not really an expert, but since @magicus approved, looks sensible to me.

Thank you @lahodaj

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

PR Comment: https://git.openjdk.org/jtreg/pull/237#issuecomment-2623743032

From cstein at openjdk.org  Thu Jan 30 09:12:02 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 30 Jan 2025 09:12:02 GMT
Subject: RFR: 7903931: Add "test.thread.factory" property to filter tests
 based on test thread factory value [v3]
In-Reply-To: <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
 <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
Message-ID: <_SlLgk6y6ATnC3jxliTXwbtjUz3PWifUiWUOhJO7d24=.f4785edf-9b75-4d9d-ba35-213fdaaf725d@github.com>

On Tue, 28 Jan 2025 17:47:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
>> 
>> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
>> 
>> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
>> 
>> The only jtreg knows if -testThreadFactory is set so it should set corresponding property
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test.thread.factory is not a property for tag spec

src/share/classes/com/sun/javatest/regtest/config/RegressionContext.java line 105:

> 103: 
> 104:         String testThreadFactory = (params == null || params.getTestThreadFactory() == null)
> 105:                 ? "null"

Having `null` as the value for "no test thread factory available" is right choice regarding easier handling on the use-site?

Or would skipping the `values.put()` call be a better default? ?

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/242#discussion_r1935254685

From cstein at openjdk.org  Thu Jan 30 09:23:03 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 30 Jan 2025 09:23:03 GMT
Subject: RFR: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <64i7e8B-OVh6PsaU8ySc3nqlYBK0K8dMdndiHwAP-lg=.594f1f10-208e-41c5-b9d4-638f26cb954b@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

Marked as reviewed by cstein (Committer).

> ?? To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

Happy to sponsor your PR, after you commented with `/integrate`, @snake66.

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

PR Review: https://git.openjdk.org/jtreg/pull/237#pullrequestreview-2583341056
PR Comment: https://git.openjdk.org/jtreg/pull/237#issuecomment-2623941285

From cstein at openjdk.org  Thu Jan 30 09:29:01 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 30 Jan 2025 09:29:01 GMT
Subject: RFR: 7903935: --verify-exclude existence check misses tests with
 failing requires
In-Reply-To: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>
References: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>
Message-ID: <NrZw3HGDgNU4M-RWwF5fvgwgZ0e3Tt4A2Fe7JJO95ko=.67848edd-04c3-429b-9cd1-e5a73fa7193f@github.com>

On Tue, 21 Jan 2025 14:20:25 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> The current implementation relies on
>   getResultsIterator
> which in turn calls into
>   TestResultTable.getIterator(filters)
> passing into jtharness. That seems to currently filter out tests that don't meet the local "requires" criteria. Thus we fail to collect all "existing" tests in to a set to compare with.
> 
> The fix seems to be to explicitly pass an empty list of filters into
>   TestResultTable.getIterator(filters)
> as this will make
>   TRT_Iterator.wouldAccept()
> accept every test.

Looks good to me.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jtreg/pull/243#pullrequestreview-2583357092

From duke at openjdk.org  Thu Jan 30 09:33:06 2025
From: duke at openjdk.org (snake66)
Date: Thu, 30 Jan 2025 09:33:06 GMT
Subject: Integrated: 7903920: Support building jtreg on FreeBSD
In-Reply-To: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
References: <VfhxDqf3UIdYdFHrGrHnB74q4gyr2-j_deE9GboWwuo=.a323aa77-4520-4bf0-84c9-1a4442f2fa26@github.com>
Message-ID: <vHnT9y4xR_4nEVqkjBpB1wzxOEs-eCG_0IE8yCZ1wjM=.dcae1581-c12f-4bb4-9797-74c93cc27a92@github.com>

On Sat, 14 Dec 2024 10:48:09 GMT, snake66 <duke at openjdk.org> wrote:

> On FreeBSD we need to use GNU gmake instead of the BSD make program.

This pull request has now been integrated.

Changeset: 081b8f78
Author:    Harald Eilertsen <haraldei at anduin.net>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/081b8f78292a01a6a3c354291318e9d648da9719
Stats:     32 lines in 3 files changed: 31 ins; 0 del; 1 mod

7903920: Support building jtreg on FreeBSD

Reviewed-by: ihse, jlahoda, cstein

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

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

From lmesnik at openjdk.org  Thu Jan 30 17:49:05 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 Jan 2025 17:49:05 GMT
Subject: RFR: 7903931: Add "test.thread.factory" property to filter tests
 based on test thread factory value [v3]
In-Reply-To: <_SlLgk6y6ATnC3jxliTXwbtjUz3PWifUiWUOhJO7d24=.f4785edf-9b75-4d9d-ba35-213fdaaf725d@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
 <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
 <_SlLgk6y6ATnC3jxliTXwbtjUz3PWifUiWUOhJO7d24=.f4785edf-9b75-4d9d-ba35-213fdaaf725d@github.com>
Message-ID: <NkBUGCrriwQTHHhVU1MeSHNQbKbS8ZyD5axCUhvOSgk=.10a0ce6b-0034-4a70-89d0-1ee03757d706@github.com>

On Thu, 30 Jan 2025 09:09:26 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test.thread.factory is not a property for tag spec
>
> src/share/classes/com/sun/javatest/regtest/config/RegressionContext.java line 105:
> 
>> 103: 
>> 104:         String testThreadFactory = (params == null || params.getTestThreadFactory() == null)
>> 105:                 ? "null"
> 
> Having `null` as the value for "no test thread factory available" is right choice regarding easier handling on the use-site?
> 
> Or would skipping the `values.put()` call be a better default? ?

I haven't checked but it should be considered as a "invalid name" if we don't put any value.
Also, want to be consistent with other properties, that just have some default value, often "null".

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/242#discussion_r1936040967

From cstein at openjdk.org  Thu Jan 30 17:53:58 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 30 Jan 2025 17:53:58 GMT
Subject: RFR: 7903931: Add "test.thread.factory" property to filter tests
 based on test thread factory value [v3]
In-Reply-To: <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
 <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
Message-ID: <IJDC1ofh7RJHfvIaTday_qexsf1TzvPd3YGSQD59InA=.4825d3bc-45ac-4659-849b-5dca225fb297@github.com>

On Tue, 28 Jan 2025 17:47:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
>> 
>> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
>> 
>> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
>> 
>> The only jtreg knows if -testThreadFactory is set so it should set corresponding property
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test.thread.factory is not a property for tag spec

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jtreg/pull/242#pullrequestreview-2584638761

From iris at openjdk.org  Thu Jan 30 18:13:21 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 30 Jan 2025 18:13:21 GMT
Subject: RFR: 7903935: --verify-exclude existence check misses tests with
 failing requires
In-Reply-To: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>
References: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>
Message-ID: <kN0UxAhz_2w5-VJhITRTDOebhSPvvTKkTflPt3jTU-g=.1522e8a6-7c27-473f-8d9b-18a26dbf403c@github.com>

On Tue, 21 Jan 2025 14:20:25 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> The current implementation relies on
>   getResultsIterator
> which in turn calls into
>   TestResultTable.getIterator(filters)
> passing into jtharness. That seems to currently filter out tests that don't meet the local "requires" criteria. Thus we fail to collect all "existing" tests in to a set to compare with.
> 
> The fix seems to be to explicitly pass an empty list of filters into
>   TestResultTable.getIterator(filters)
> as this will make
>   TRT_Iterator.wouldAccept()
> accept every test.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/243#pullrequestreview-2584672030

From iris at openjdk.org  Fri Jan 31 04:29:06 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 31 Jan 2025 04:29:06 GMT
Subject: RFR: 7903931: Add "test.thread.factory" property to filter tests
 based on test thread factory value [v3]
In-Reply-To: <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
 <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
Message-ID: <iJqK9dzS-RlVLGJXkfRd0ywtNvg0d69-jfavzMQ5BX8=.c49a41ef-0584-4734-b299-758cf21f73f7@github.com>

On Tue, 28 Jan 2025 17:47:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
>> 
>> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
>> 
>> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
>> 
>> The only jtreg knows if -testThreadFactory is set so it should set corresponding property
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test.thread.factory is not a property for tag spec

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/242#pullrequestreview-2585639147

From lujaniuk at openjdk.org  Fri Jan 31 09:13:00 2025
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Fri, 31 Jan 2025 09:13:00 GMT
Subject: Integrated: 7903935: --verify-exclude existence check misses tests
 with failing requires
In-Reply-To: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>
References: <Q6WEIDOzm88dxfK4ejocUT8SWbZjM5IT_OzNAcI4Z_g=.7d981732-20d2-4e58-89c3-ed09c92fd687@github.com>
Message-ID: <LqnuwhoOuIRHrHXp0mU1eYPc4VTnDaQXXQBTi0XJWbw=.5b6b2fb8-c34c-411e-8957-bafacb113ee9@github.com>

On Tue, 21 Jan 2025 14:20:25 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> The current implementation relies on
>   getResultsIterator
> which in turn calls into
>   TestResultTable.getIterator(filters)
> passing into jtharness. That seems to currently filter out tests that don't meet the local "requires" criteria. Thus we fail to collect all "existing" tests in to a set to compare with.
> 
> The fix seems to be to explicitly pass an empty list of filters into
>   TestResultTable.getIterator(filters)
> as this will make
>   TRT_Iterator.wouldAccept()
> accept every test.

This pull request has now been integrated.

Changeset: 60909fe0
Author:    Ludvig Janiuk <lujaniuk at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/60909fe0785f1d1a3397dd644de7b42c3542121a
Stats:     10 lines in 1 file changed: 9 ins; 0 del; 1 mod

7903935: --verify-exclude existence check misses tests with failing requires

Reviewed-by: cstein, iris

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

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