From duke at openjdk.org  Thu Jun  5 04:48:13 2025
From: duke at openjdk.org (Pasam Soujanya)
Date: Thu, 5 Jun 2025 04:48:13 GMT
Subject: RFR: 7904021: Parsing group files(TEST.GROUPS) on non-UTF-8 encoding
 platforms fails with java.nio.charset.MalformedInputException
Message-ID: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>

Parsing group files(TEST.GROUPS) on non-UTF-8 encoding platforms fails with java.nio.charset.MalformedInputException.

Error:
Error: Cannot read group files for /test/jdk: java.nio.charset.MalformedInputException: Input length = 1
---------
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue

### Error
&nbsp;?? The pull request body must not be empty.

### Integration blocker
&nbsp;?? Title mismatch between PR and JBS for issue [CODETOOLS-7904021](https://bugs.openjdk.org/browse/CODETOOLS-7904021)



### Reviewing
<details><summary>Using <code>git</code></summary>

Checkout this PR locally: \
`$ git fetch https://git.openjdk.org/jtreg.git pull/267/head:pull/267` \
`$ git checkout pull/267`

Update a local copy of the PR: \
`$ git checkout pull/267` \
`$ git pull https://git.openjdk.org/jtreg.git pull/267/head`

</details>
<details><summary>Using Skara CLI tools</summary>

Checkout this PR locally: \
`$ git pr checkout 267`

View PR using the GUI difftool: \
`$ git pr show -t 267`

</details>
<details><summary>Using diff file</summary>

Download this PR as a diff file: \
<a href="https://git.openjdk.org/jtreg/pull/267.diff">https://git.openjdk.org/jtreg/pull/267.diff</a>

</details>

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

Commit messages:
 - Merge branch 'master' of github.com:psoujany/jtreg
 - Read InputStream in defaultCharset

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

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

From cstein at openjdk.org  Mon Jun  9 20:50:42 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 9 Jun 2025 20:50:42 GMT
Subject: RFR: 7904021: Parsing group files(TEST.GROUPS) on non-UTF-8
 encoding platforms fails with java.nio.charset.MalformedInputException
In-Reply-To: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
References: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
Message-ID: <PLgSoQz0x7TN5W2SB47J2cIqHa0ePoR8suOAuavyHtg=.aeb81b66-01ff-4b0b-b054-ee6c4fc8e80f@github.com>

On Thu, 5 Jun 2025 04:35:14 GMT, Pasam Soujanya <duke at openjdk.org> wrote:

> Parsing group files(TEST.GROUPS) on non-UTF-8 encoding platforms fails with java.nio.charset.MalformedInputException.
> 
> Error:
> Error: Cannot read group files for /test/jdk: java.nio.charset.MalformedInputException: Input length = 1
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
> &nbsp;?? The pull request body must not be empty.
> 
> ### Integration blocker
> &nbsp;?? Title mismatch between PR and JBS for issue [CODETOOLS-7904021](https://bugs.openjdk.org/browse/CODETOOLS-7904021)
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jtreg.git pull/267/head:pull/267` \
> `$ git checkout pull/267`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/267` \
> `$ git pull https://git.openjdk.org/jtreg.git pull/267/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 267`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 267`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jtreg/pull/267.diff">https://git.openjdk.org/jtreg/pull/267.diff</a>
> 
> </details>

Looking at the former implementation, without NIO API usage, the file read by those methods were assumed to be encoded in `ISO 8859-1`. Defaulting to `UTF-8` was a breaking change, although storing files in `UTF-8` nowadays is a common pattern.

Using `Charset.defaultCharset()` as proposed in the pull request introduces yet another behaviour. Maybe better? Another solution would be to revert to use the original `ISO 8859-1`. ?

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

PR Comment: https://git.openjdk.org/jtreg/pull/267#issuecomment-2956997051

From cstein at openjdk.org  Tue Jun 10 10:10:45 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Jun 2025 10:10:45 GMT
Subject: RFR: 7904021: Parsing group files(TEST.GROUPS) on non-UTF-8
 encoding platforms fails with java.nio.charset.MalformedInputException
In-Reply-To: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
References: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
Message-ID: <vW1eeVYHiDF4F5dJGjj9uF7N_RX4t8vrtv6ujJ0wIYA=.ccf67441-35d0-4944-805a-035010d08c15@github.com>

On Thu, 5 Jun 2025 04:35:14 GMT, Pasam Soujanya <duke at openjdk.org> wrote:

> Parsing group files(TEST.GROUPS) on non-UTF-8 encoding platforms fails with java.nio.charset.MalformedInputException.
> 
> Error:
> Error: Cannot read group files for /test/jdk: java.nio.charset.MalformedInputException: Input length = 1
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
> &nbsp;?? The pull request body must not be empty.
> 
> ### Integration blocker
> &nbsp;?? Title mismatch between PR and JBS for issue [CODETOOLS-7904021](https://bugs.openjdk.org/browse/CODETOOLS-7904021)
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jtreg.git pull/267/head:pull/267` \
> `$ git checkout pull/267`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/267` \
> `$ git pull https://git.openjdk.org/jtreg.git pull/267/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 267`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 267`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jtreg/pull/267.diff">https://git.openjdk.org/jtreg/pull/267.diff</a>
> 
> </details>

Please update the title of this PR to read: `Parsing group files using non-UTF-8 encoding fails`

Also, fix the PR body to appear not empty.

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

PR Comment: https://git.openjdk.org/jtreg/pull/267#issuecomment-2958508394

From duke at openjdk.org  Tue Jun 10 11:05:43 2025
From: duke at openjdk.org (Pasam Soujanya)
Date: Tue, 10 Jun 2025 11:05:43 GMT
Subject: RFR: 7904021: Parsing group files using non-UTF-8 encoding fails
In-Reply-To: <vW1eeVYHiDF4F5dJGjj9uF7N_RX4t8vrtv6ujJ0wIYA=.ccf67441-35d0-4944-805a-035010d08c15@github.com>
References: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
 <vW1eeVYHiDF4F5dJGjj9uF7N_RX4t8vrtv6ujJ0wIYA=.ccf67441-35d0-4944-805a-035010d08c15@github.com>
Message-ID: <7npNPplvS6gbZ9fRgPe1euUwZuOC4VEmaF-YUewHsMU=.63d9c348-8c8c-4ff7-a9ad-4c64f0036a7d@github.com>

On Tue, 10 Jun 2025 10:07:56 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> We make use of jtreg to execute openjdk tests for JDK11/17/21 releases on non-UTF-8 returning platforms. We found latest jtreg code is using Files.newBufferedReader(path) to read group files data(TEST.GROUPS) from openjdk via GroupManager (https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/GroupManager.java#L102C44-L102C61). 
>> 
>> This code defaults to return BufferedReader as UTF-8 instance. We see discrepancies when using this version of jtreg on non-UTF-8 platforms where defaultCharset() is non-UTF-8(JDK11 and JDK17).
>> 
>> Hence, we would like to propose a fix of using default.Charset() with Files.newBufferedWriter(Path path, Charset cs) instead of Files.newBufferedReader(path) and Files.readString(Path) to Files.readString(Path,Charset cs) in below jtreg files :
>> https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/GroupManager.java#L102C44-L102C61
>> https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/ExtraPropDefns.java#L309
>> 
>> We've also tested this fix on OpenJDK supported platforms like Linux, Windows, MAC. 
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jtreg.git pull/267/head:pull/267` \
>> `$ git checkout pull/267`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/267` \
>> `$ git pull https://git.openjdk.org/jtreg.git pull/267/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 267`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 267`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jtreg/pull/267.diff">https://git.openjdk.org/jtreg/pull/267.diff</a>
>> 
>> </details>
>> <details><summary>Using Webrev</summary>
>> 
>> [Link to Webrev Comment](https://git.openjdk.org/jtreg/pull/267#issuecomment-2942734568)
>> </details>
>
> Please update the title of this PR to read: `Parsing group files using non-UTF-8 encoding fails`
> 
> Also, fix the PR body to appear not empty.

@sormuras I've updated the PR title and body. Thank you.

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

PR Comment: https://git.openjdk.org/jtreg/pull/267#issuecomment-2958720134

From cstein at openjdk.org  Tue Jun 10 12:54:44 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Jun 2025 12:54:44 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v12]
In-Reply-To: <bqUbaO7aRhzrLaXx_EXcL_SkBaJA9s_KcSqGlesdXjs=.8937b67c-3be0-41a3-837b-ea0b0ba91e1c@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <bqUbaO7aRhzrLaXx_EXcL_SkBaJA9s_KcSqGlesdXjs=.8937b67c-3be0-41a3-837b-ea0b0ba91e1c@github.com>
Message-ID: <AisiMs1rW0k6Ui-wdS_FiKoqoF0g3UJaQ_0qD4QU6Uo=.42af4cb7-1330-4246-9518-5c9ead06cf0e@github.com>

On Fri, 18 Apr 2025 02:21:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

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

Please update this branch to the latest of `openjdk/jtreg` to include bug fixes and features introduced by https://github.com/lmesnik/jtreg/compare/7902847...openjdk%3Ajtreg%3Amaster

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

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

From lmesnik at openjdk.org  Tue Jun 10 17:31:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 10 Jun 2025 17:31:28 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v13]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <AU8udGfOw20evEjt1w5ABybkZ_qiQ0dYDKQaIka0C1o=.a3fb9c8a-382e-447e-b9d1-3eff6893362c@github.com>

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

Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' of https://github.com/openjdk/jtreg into 7902847
 - fx
 - Merge branch '7902847' of https://github.com/lmesnik/jtreg into 7902847
 - Update src/share/doc/javatest/regtest/tag-spec.html
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - fixed spec
 - fixed typo
 - Merge branch 'master' of https://github.com/openjdk/jtreg into 7902847
 - added test for legacy option
 - incorrectly updated var
 - the propery was added to revert sharing of libraries
 - ... and 6 more: https://git.openjdk.org/jtreg/compare/666453dc...cd30631a

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

Changes: https://git.openjdk.org/jtreg/pull/256/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=256&range=12
  Stats: 271 lines in 13 files changed: 225 ins; 12 del; 34 mod
  Patch: https://git.openjdk.org/jtreg/pull/256.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/256/head:pull/256

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

From cstein at openjdk.org  Mon Jun 16 16:28:41 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 16 Jun 2025 16:28:41 GMT
Subject: RFR: 7904021: Parsing group files using non-UTF-8 encoding fails
In-Reply-To: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
References: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
Message-ID: <H6CT9Sp3ABu0369L6dYJOmDcZbDcmmYttCJf77tB6VM=.8daf667b-db68-46dd-ae24-e1b850da4a8d@github.com>

On Thu, 5 Jun 2025 04:35:14 GMT, Pasam Soujanya <duke at openjdk.org> wrote:

> We make use of jtreg to execute openjdk tests for JDK11/17/21 releases on non-UTF-8 returning platforms. We found latest jtreg code is using Files.newBufferedReader(path) to read group files data(TEST.GROUPS) from openjdk via GroupManager (https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/GroupManager.java#L102C44-L102C61). 
> 
> This code defaults to return BufferedReader as UTF-8 instance. We see discrepancies when using this version of jtreg on non-UTF-8 platforms where defaultCharset() is non-UTF-8(JDK11 and JDK17).
> 
> Hence, we would like to propose a fix of using default.Charset() with Files.newBufferedWriter(Path path, Charset cs) instead of Files.newBufferedReader(path) and Files.readString(Path) to Files.readString(Path,Charset cs) in below jtreg files :
> https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/GroupManager.java#L102C44-L102C61
> https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/ExtraPropDefns.java#L309
> 
> We've also tested this fix on OpenJDK supported platforms like Linux, Windows, MAC. 
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jtreg.git pull/267/head:pull/267` \
> `$ git checkout pull/267`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/267` \
> `$ git pull https://git.openjdk.org/jtreg.git pull/267/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 267`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 267`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jtreg/pull/267.diff">https://git.openjdk.org/jtreg/pull/267.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jtreg/pull/267#issuecomment-2942734568)
> </details>

The two places changed in this PR aren't all places in which `jtreg` reads input from files. Not touch those other places might lead to unexpected/divergent behaviour.

With https://openjdk.org/jeps/400 UTF-8 is the default charset of the standard Java APIs. Yes, that relates to Java 18+, but did you try to store those group files in UTF-8 encoding in your local environment?

Did you try passing `file.encoding` as a system property to the `jtreg` runtime? For example: `jtreg -J-Dfile.encoding=ISO-8859-1 ...`

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

PR Comment: https://git.openjdk.org/jtreg/pull/267#issuecomment-2977271129

From duke at openjdk.org  Wed Jun 18 11:24:43 2025
From: duke at openjdk.org (Pasam Soujanya)
Date: Wed, 18 Jun 2025 11:24:43 GMT
Subject: RFR: 7904021: Parsing group files using non-UTF-8 encoding fails
In-Reply-To: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
References: <35KNELPODav-BiVnxzITTKeQ4XidiUix4AgoIj1Ovjk=.d157b637-2a6f-4bdb-b709-60a26241d3ce@github.com>
Message-ID: <ur9mynsWiGe107utEYmoyG5SrXJcVcajIT5BUtMDnns=.031ebca3-921b-46b0-8dd7-99280ec9b907@github.com>

On Thu, 5 Jun 2025 04:35:14 GMT, Pasam Soujanya <duke at openjdk.org> wrote:

> We make use of jtreg to execute openjdk tests for JDK11/17/21 releases on non-UTF-8 returning platforms. We found latest jtreg code is using Files.newBufferedReader(path) to read group files data(TEST.GROUPS) from openjdk via GroupManager (https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/GroupManager.java#L102C44-L102C61). 
> 
> This code defaults to return BufferedReader as UTF-8 instance. We see discrepancies when using this version of jtreg on non-UTF-8 platforms where defaultCharset() is non-UTF-8(JDK11 and JDK17).
> 
> Hence, we would like to propose a fix of using default.Charset() with Files.newBufferedWriter(Path path, Charset cs) instead of Files.newBufferedReader(path) and Files.readString(Path) to Files.readString(Path,Charset cs) in below jtreg files :
> https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/GroupManager.java#L102C44-L102C61
> https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/ExtraPropDefns.java#L309
> 
> We've also tested this fix on OpenJDK supported platforms like Linux, Windows, MAC. 
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jtreg.git pull/267/head:pull/267` \
> `$ git checkout pull/267`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/267` \
> `$ git pull https://git.openjdk.org/jtreg.git pull/267/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 267`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 267`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jtreg/pull/267.diff">https://git.openjdk.org/jtreg/pull/267.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jtreg/pull/267#issuecomment-2942734568)
> </details>

In our testing we noticed these 2 places which resolved our issue, will check other places where the change is required. 

Yes, we tried keeping `TEST.groups` in UTF-8 this led to asking `.java` files too in UTF-8. If we place .java files in UTF-8 then we had encountered `javac` compilation issues due to encoding mismatch(non UTF-8) platforms.

We also tried passing `file.encoding` to jtreg but still faced Malformed Error. Hence, we used Charset.defaultCharset().

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

PR Comment: https://git.openjdk.org/jtreg/pull/267#issuecomment-2983790265

From jpai at openjdk.org  Tue Jun 24 07:54:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Jun 2025 07:54:53 GMT
Subject: RFR: 7904045: Remove the macOS version check from jtreg
Message-ID: <PaWb1ddfkq4sJQ7jhN2yZ2EFNDSh1HFu7kttuqWE6L4=.f72fb78e-2972-4e91-ad12-242b344fdcf7@github.com>

Can I please get a review of this change which proposes to remove the macOS version check in jtreg tool? As noted in https://bugs.openjdk.org/browse/CODETOOLS-7904045, the current check results in jtreg exiting the process if it finds a mismatch in the macOS version reported by `sw_vers` tool and the one reported by Java's `os.version` system property. This makes it impossible to launch jtreg to run any tests on macOS 26 (currently in Beta). Even a fix in the JDK (through https://bugs.openjdk.org/browse/JDK-8359830) won't be enough because older versions of the JDK that could be used to launch the jtreg process will still cause this check to fail in jtreg.

The check itself isn't necessary within jtreg and that version check should instead reside as a regression test within the JDK repo. In fact there's already a regression test in JDK which catches these issues related to incorrect os.version reporting. Having this check in jtreg (that too only for macOS) prevents the tool from being used on these newer versions of macOS. In fact, jtreg itself cannot be built (with JDK 17) on macOS 26 (beta) due to this check.

The commit in this PR removes the check. I have run this change against macOS 26 (beta) where the tool would previously exit. The self-tests now all pass on that host:


All (     234) selected tests completed successfully

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

Commit messages:
 - 7904045: Remove the macOS version check from jtreg

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

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

From cstein at openjdk.org  Tue Jun 24 08:05:41 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 08:05:41 GMT
Subject: RFR: 7904045: Remove the macOS version check from jtreg
In-Reply-To: <PaWb1ddfkq4sJQ7jhN2yZ2EFNDSh1HFu7kttuqWE6L4=.f72fb78e-2972-4e91-ad12-242b344fdcf7@github.com>
References: <PaWb1ddfkq4sJQ7jhN2yZ2EFNDSh1HFu7kttuqWE6L4=.f72fb78e-2972-4e91-ad12-242b344fdcf7@github.com>
Message-ID: <2mfR28IrCndccVeQBfgl4Wd9RQo3s3vuyFtcry-ECRo=.2bcea932-faeb-4f04-ade1-a6956a1c79b8@github.com>

On Tue, 24 Jun 2025 07:51:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the macOS version check in jtreg tool? As noted in https://bugs.openjdk.org/browse/CODETOOLS-7904045, the current check results in jtreg exiting the process if it finds a mismatch in the macOS version reported by `sw_vers` tool and the one reported by Java's `os.version` system property. This makes it impossible to launch jtreg to run any tests on macOS 26 (currently in Beta). Even a fix in the JDK (through https://bugs.openjdk.org/browse/JDK-8359830) won't be enough because older versions of the JDK that could be used to launch the jtreg process will still cause this check to fail in jtreg.
> 
> The check itself isn't necessary within jtreg and that version check should instead reside as a regression test within the JDK repo. In fact there's already a regression test in JDK which catches these issues related to incorrect os.version reporting. Having this check in jtreg (that too only for macOS) prevents the tool from being used on these newer versions of macOS. In fact, jtreg itself cannot be built (with JDK 17) on macOS 26 (beta) due to this check.
> 
> The commit in this PR removes the check. I have run this change against macOS 26 (beta) where the tool would previously exit. The self-tests now all pass on that host:
> 
> 
> All (     234) selected tests completed successfully

The check was introduced in commit https://github.com/openjdk/jtreg/commit/84ac040e6e9cc281a5bc19a87f5b082e9febb560 without much reasoning recorded in https://bugs.openjdk.org/browse/CODETOOLS-7903088.

As long as the OS version is still recorded when running `jtreg` for troubleshooting issues, I am fine with removin the check.

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

PR Comment: https://git.openjdk.org/jtreg/pull/268#issuecomment-2999247744

From cstein at openjdk.org  Tue Jun 24 08:46:41 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 08:46:41 GMT
Subject: RFR: 7904045: Remove the macOS version check from jtreg
In-Reply-To: <PaWb1ddfkq4sJQ7jhN2yZ2EFNDSh1HFu7kttuqWE6L4=.f72fb78e-2972-4e91-ad12-242b344fdcf7@github.com>
References: <PaWb1ddfkq4sJQ7jhN2yZ2EFNDSh1HFu7kttuqWE6L4=.f72fb78e-2972-4e91-ad12-242b344fdcf7@github.com>
Message-ID: <sbEegXrkwvQfwurLsKXX4fn9JQsiXKHMKh8oOPZvaHY=.3be8c667-15de-47d6-b83d-1f14c86a8196@github.com>

On Tue, 24 Jun 2025 07:51:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the macOS version check in jtreg tool? As noted in https://bugs.openjdk.org/browse/CODETOOLS-7904045, the current check results in jtreg exiting the process if it finds a mismatch in the macOS version reported by `sw_vers` tool and the one reported by Java's `os.version` system property. This makes it impossible to launch jtreg to run any tests on macOS 26 (currently in Beta). Even a fix in the JDK (through https://bugs.openjdk.org/browse/JDK-8359830) won't be enough because older versions of the JDK that could be used to launch the jtreg process will still cause this check to fail in jtreg.
> 
> The check itself isn't necessary within jtreg and that version check should instead reside as a regression test within the JDK repo. In fact there's already a regression test in JDK which catches these issues related to incorrect os.version reporting. Having this check in jtreg (that too only for macOS) prevents the tool from being used on these newer versions of macOS. In fact, jtreg itself cannot be built (with JDK 17) on macOS 26 (beta) due to this check.
> 
> The commit in this PR removes the check. I have run this change against macOS 26 (beta) where the tool would previously exit. The self-tests now all pass on that host:
> 
> 
> All (     234) selected tests completed successfully

Marked as reviewed by cstein (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/268#pullrequestreview-2952772995

From jpai at openjdk.org  Tue Jun 24 08:46:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Jun 2025 08:46:41 GMT
Subject: RFR: 7904045: Remove the macOS version check from jtreg
In-Reply-To: <2mfR28IrCndccVeQBfgl4Wd9RQo3s3vuyFtcry-ECRo=.2bcea932-faeb-4f04-ade1-a6956a1c79b8@github.com>
References: <PaWb1ddfkq4sJQ7jhN2yZ2EFNDSh1HFu7kttuqWE6L4=.f72fb78e-2972-4e91-ad12-242b344fdcf7@github.com>
 <2mfR28IrCndccVeQBfgl4Wd9RQo3s3vuyFtcry-ECRo=.2bcea932-faeb-4f04-ade1-a6956a1c79b8@github.com>
Message-ID: <LEzZNZcZwegp6QCXiObLh38FXi0SwwWXpUFgtLBtJ7c=.a91b46c8-f1f5-4a6f-a106-1ffbecb2137f@github.com>

On Tue, 24 Jun 2025 08:02:33 GMT, Christian Stein <cstein at openjdk.org> wrote:

> As long as the OS version is still recorded when running jtreg for troubleshooting issues

That's correct, no changes in that area and jtreg will continue to report the OS version in the relevant places like the jtr file of the test.

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

PR Comment: https://git.openjdk.org/jtreg/pull/268#issuecomment-2999378399

From cstein at openjdk.org  Tue Jun 24 14:58:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 14:58:19 GMT
Subject: RFR: 7904046: Update jtreg to bundle JUnit 5.13.2
Message-ID: <5qmBHrpzU8g9rTaKBOu-c3eMZQ-Jlsns1EiuHWVjVaY=.68446dde-585e-401f-acc1-7e8d43bd73ee@github.com>

Please review this change to update jtreg to bundle a newer version of JUnit, namely `5.13.2`.

In addition to "Numerous bug fixes and minor improvements" compared to older versions the `@ParameterizedClass` feature would be a major win for writing parameterized tests and the new validation feature that reports configuration error at test discovery time.

[JUnit 5.13 Scope](https://docs.junit.org/5.13.2/release-notes/#release-notes-5.13.0)

- Introduce @ClassTemplate and @ParameterizedClass support in JUnit Jupiter
- Access to ParameterInfo for JUnit Jupiter extensions
- New @SentenceFragment annotation for use with IndicativeSentences display name generator
- Add --redirect-stdout and --redirect-stderr options to ConsoleLauncher
- Introduce test discovery support in EngineTestKit
- Reporting of discovery issues for test engines
- Resource management for launcher sessions and execution requests
- GraalVM: removal of native-image.properties files from JARs

[JUnit 5.12 Scope](https://docs.junit.org/5.12.0/release-notes/index.html#release-notes-5.12.0)

- Output file attachments for tests and containers
- Improvements to the Open Test Reporting XML output
- Resource lock definition improvements
- Thread dumps on test timeouts
- Parameterized test validation improvements
- Filtering support for auto-registered extensions
- Kotlin contracts for assertions
- Configurable Jupiter extension context scope
- Enhancements to the ConsoleLauncher
- Better support for GraalVM native image usage
- Improved discovery support for file-based test engines
- Customizable classpath scanning
- Parallel execution support in JUnit Vintage engine

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

Commit messages:
 - 7904046: Update jtreg to bundle JUnit 5.13.2

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

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

From iris at openjdk.org  Tue Jun 24 15:42:47 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 24 Jun 2025 15:42:47 GMT
Subject: RFR: 7904046: Update jtreg to bundle JUnit 5.13.2
In-Reply-To: <5qmBHrpzU8g9rTaKBOu-c3eMZQ-Jlsns1EiuHWVjVaY=.68446dde-585e-401f-acc1-7e8d43bd73ee@github.com>
References: <5qmBHrpzU8g9rTaKBOu-c3eMZQ-Jlsns1EiuHWVjVaY=.68446dde-585e-401f-acc1-7e8d43bd73ee@github.com>
Message-ID: <3rXDTug4pP75jX8930bv74RrOOdxCnz_3zGzy8_7IQM=.3470ba5d-94cb-49e1-aa12-9dc1c5cb0ee3@github.com>

On Tue, 24 Jun 2025 14:54:32 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to update jtreg to bundle a newer version of JUnit, namely `5.13.2`.
> 
> In addition to "Numerous bug fixes and minor improvements" compared to older versions the `@ParameterizedClass` feature would be a major win for writing parameterized tests and the new validation feature that reports configuration error at test discovery time.
> 
> [JUnit 5.13 Scope](https://docs.junit.org/5.13.2/release-notes/#release-notes-5.13.0)
> 
> - Introduce @ClassTemplate and @ParameterizedClass support in JUnit Jupiter
> - Access to ParameterInfo for JUnit Jupiter extensions
> - New @SentenceFragment annotation for use with IndicativeSentences display name generator
> - Add --redirect-stdout and --redirect-stderr options to ConsoleLauncher
> - Introduce test discovery support in EngineTestKit
> - Reporting of discovery issues for test engines
> - Resource management for launcher sessions and execution requests
> - GraalVM: removal of native-image.properties files from JARs
> 
> [JUnit 5.12 Scope](https://docs.junit.org/5.12.0/release-notes/index.html#release-notes-5.12.0)
> 
> - Output file attachments for tests and containers
> - Improvements to the Open Test Reporting XML output
> - Resource lock definition improvements
> - Thread dumps on test timeouts
> - Parameterized test validation improvements
> - Filtering support for auto-registered extensions
> - Kotlin contracts for assertions
> - Configurable Jupiter extension context scope
> - Enhancements to the ConsoleLauncher
> - Better support for GraalVM native image usage
> - Improved discovery support for file-based test engines
> - Customizable classpath scanning
> - Parallel execution support in JUnit Vintage engine

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/269#pullrequestreview-2954403020

From cstein at openjdk.org  Tue Jun 24 17:40:58 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 17:40:58 GMT
Subject: RFR: 7904046: Update jtreg to bundle JUnit 5.13.2 [v2]
In-Reply-To: <5qmBHrpzU8g9rTaKBOu-c3eMZQ-Jlsns1EiuHWVjVaY=.68446dde-585e-401f-acc1-7e8d43bd73ee@github.com>
References: <5qmBHrpzU8g9rTaKBOu-c3eMZQ-Jlsns1EiuHWVjVaY=.68446dde-585e-401f-acc1-7e8d43bd73ee@github.com>
Message-ID: <Xw3pAxruasBJkJJJEBpdxRiMJ_0pK1Tk6fbNrbwAkmc=.04dbdd3a-d883-4cfa-a399-c24a888b8dcb@github.com>

> Please review this change to update jtreg to bundle a newer version of JUnit, namely `5.13.2`.
> 
> In addition to "Numerous bug fixes and minor improvements" compared to older versions the `@ParameterizedClass` feature would be a major win for writing parameterized tests and the new validation feature that reports configuration error at test discovery time.
> 
> [JUnit 5.13 Scope](https://docs.junit.org/5.13.2/release-notes/#release-notes-5.13.0)
> 
> - Introduce @ClassTemplate and @ParameterizedClass support in JUnit Jupiter
> - Access to ParameterInfo for JUnit Jupiter extensions
> - New @SentenceFragment annotation for use with IndicativeSentences display name generator
> - Add --redirect-stdout and --redirect-stderr options to ConsoleLauncher
> - Introduce test discovery support in EngineTestKit
> - Reporting of discovery issues for test engines
> - Resource management for launcher sessions and execution requests
> - GraalVM: removal of native-image.properties files from JARs
> 
> [JUnit 5.12 Scope](https://docs.junit.org/5.12.0/release-notes/index.html#release-notes-5.12.0)
> 
> - Output file attachments for tests and containers
> - Improvements to the Open Test Reporting XML output
> - Resource lock definition improvements
> - Thread dumps on test timeouts
> - Parameterized test validation improvements
> - Filtering support for auto-registered extensions
> - Kotlin contracts for assertions
> - Configurable Jupiter extension context scope
> - Enhancements to the ConsoleLauncher
> - Better support for GraalVM native image usage
> - Improved discovery support for file-based test engines
> - Customizable classpath scanning
> - Parallel execution support in JUnit Vintage engine

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

  Update expected failure message

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/269/files
  - new: https://git.openjdk.org/jtreg/pull/269/files/8339a64a..bc9193eb

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

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

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

From iris at openjdk.org  Tue Jun 24 17:48:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 24 Jun 2025 17:48:51 GMT
Subject: RFR: 7904046: Update jtreg to bundle JUnit 5.13.2 [v2]
In-Reply-To: <Xw3pAxruasBJkJJJEBpdxRiMJ_0pK1Tk6fbNrbwAkmc=.04dbdd3a-d883-4cfa-a399-c24a888b8dcb@github.com>
References: <5qmBHrpzU8g9rTaKBOu-c3eMZQ-Jlsns1EiuHWVjVaY=.68446dde-585e-401f-acc1-7e8d43bd73ee@github.com>
 <Xw3pAxruasBJkJJJEBpdxRiMJ_0pK1Tk6fbNrbwAkmc=.04dbdd3a-d883-4cfa-a399-c24a888b8dcb@github.com>
Message-ID: <k_n4aL8Icz6U9GlENnBJpnw4zO_qjG6X3MOXnCB5Hng=.7fab886c-64bc-4837-9f19-2e05490ba73a@github.com>

On Tue, 24 Jun 2025 17:40:58 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to update jtreg to bundle a newer version of JUnit, namely `5.13.2`.
>> 
>> In addition to "Numerous bug fixes and minor improvements" compared to older versions the `@ParameterizedClass` feature would be a major win for writing parameterized tests and the new validation feature that reports configuration error at test discovery time.
>> 
>> [JUnit 5.13 Scope](https://docs.junit.org/5.13.2/release-notes/#release-notes-5.13.0)
>> 
>> - Introduce @ClassTemplate and @ParameterizedClass support in JUnit Jupiter
>> - Access to ParameterInfo for JUnit Jupiter extensions
>> - New @SentenceFragment annotation for use with IndicativeSentences display name generator
>> - Add --redirect-stdout and --redirect-stderr options to ConsoleLauncher
>> - Introduce test discovery support in EngineTestKit
>> - Reporting of discovery issues for test engines
>> - Resource management for launcher sessions and execution requests
>> - GraalVM: removal of native-image.properties files from JARs
>> 
>> [JUnit 5.12 Scope](https://docs.junit.org/5.12.0/release-notes/index.html#release-notes-5.12.0)
>> 
>> - Output file attachments for tests and containers
>> - Improvements to the Open Test Reporting XML output
>> - Resource lock definition improvements
>> - Thread dumps on test timeouts
>> - Parameterized test validation improvements
>> - Filtering support for auto-registered extensions
>> - Kotlin contracts for assertions
>> - Configurable Jupiter extension context scope
>> - Enhancements to the ConsoleLauncher
>> - Better support for GraalVM native image usage
>> - Improved discovery support for file-based test engines
>> - Customizable classpath scanning
>> - Parallel execution support in JUnit Vintage engine
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update expected failure message

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/269#pullrequestreview-2954773562

From lmesnik at openjdk.org  Wed Jun 25 00:17:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Jun 2025 00:17:40 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v13]
In-Reply-To: <AU8udGfOw20evEjt1w5ABybkZ_qiQ0dYDKQaIka0C1o=.a3fb9c8a-382e-447e-b9d1-3eff6893362c@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <AU8udGfOw20evEjt1w5ABybkZ_qiQ0dYDKQaIka0C1o=.a3fb9c8a-382e-447e-b9d1-3eff6893362c@github.com>
Message-ID: <Sr_Af_jHk8bBWkAJlsy8R_RqHGwbgJbm5NIhw-OEBBI=.b7791de6-b410-4cb3-bd4b-e3313e6707d9@github.com>

On Tue, 10 Jun 2025 17:31:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The classes from test libraries can be compiled implicitly as a test dependency or explicitly with @build tag.
>> 
>> For first case
>> Test library used as a source path during test compilation  and library classes as well as test classes are compiled into class directory. 
>> 
>> For 2nd case 
>> The library classes are compiled using @build tag and library classes are placed into some shared location.
>> 
>> These 2 cases might be mixed in the single test and can have part of library classes compiled into shared directory and part compiled into test classes directory.
>> 
>> jtreg uses classfiles to check if source code should be compiled. Let we have 2 classes LibA and Lib that extends LibA.
>>  So if class LibA might be  compiled into test class directory while LibB is compiled into library directory. Later  jtreg can try to use LibB class without and compilation because LibB already exists. Thus the CNFE will be thrown.
>> 
>> The another possible problem, is that the library code might include test code for libraries like "/" and "/vmTestbase"
>> so any test classes with same packages would be compiled into the same location because they are treated as library classes. So for tree like this:
>> test1/Test.java
>> test2/Test.java
>> with both tests having
>> 
>> @library "/"
>> @build Test
>> 
>> we are going just to have one Test class in library directory.
>> 
>> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test. Although it looks like huge performance overhead, the impact is low. The libraries are not often compiled using build tag. 
>> 
>> Times for tier1 execution with fix:
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 28s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 18m 14s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 15m 8s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 59s
>> 
>> and before fix
>> test-results/jtreg_test_lib_test_tier1/text/timeStats.txt:Total elapsed time 0m 32s
>> test-results/jtreg_test_hotspot_jtreg_tier1/text/timeStats.txt:Total elapsed time 17m 51s
>> test-results/jtreg_test_jdk_tier1/text/timeStats.txt:Total elapsed time 14m 49s
>> test-results/jtreg_test_langtools_tier1/text/timeStats.txt:Total elapsed time 7m 56s
>> 
>> The full fix might require more testing and adding testcase.
>> Please note that there are plans to work on the 
>> https://bugs.openjd...
>
> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jtreg into 7902847
>  - fx
>  - Merge branch '7902847' of https://github.com/lmesnik/jtreg into 7902847
>  - Update src/share/doc/javatest/regtest/tag-spec.html
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - fixed spec
>  - fixed typo
>  - Merge branch 'master' of https://github.com/openjdk/jtreg into 7902847
>  - added test for legacy option
>  - incorrectly updated var
>  - the propery was added to revert sharing of libraries
>  - ... and 6 more: https://git.openjdk.org/jtreg/compare/666453dc...cd30631a

just ping
the master is merged,
tier1-3 tested locally.

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

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

From jpai at openjdk.org  Wed Jun 25 02:22:39 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 02:22:39 GMT
Subject: RFR: 7904045: Remove the macOS version check from jtreg
In-Reply-To: <PaWb1ddfkq4sJQ7jhN2yZ2EFNDSh1HFu7kttuqWE6L4=.f72fb78e-2972-4e91-ad12-242b344fdcf7@github.com>
References: <PaWb1ddfkq4sJQ7jhN2yZ2EFNDSh1HFu7kttuqWE6L4=.f72fb78e-2972-4e91-ad12-242b344fdcf7@github.com>
Message-ID: <PrJS6qVBr_dKUmKN19VO_CCL8PpFpnbD9jNSDUZDU0U=.1207e536-0c21-4543-9979-dfa9875d0cf4@github.com>

On Tue, 24 Jun 2025 07:51:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the macOS version check in jtreg tool? As noted in https://bugs.openjdk.org/browse/CODETOOLS-7904045, the current check results in jtreg exiting the process if it finds a mismatch in the macOS version reported by `sw_vers` tool and the one reported by Java's `os.version` system property. This makes it impossible to launch jtreg to run any tests on macOS 26 (currently in Beta). Even a fix in the JDK (through https://bugs.openjdk.org/browse/JDK-8359830) won't be enough because older versions of the JDK that could be used to launch the jtreg process will still cause this check to fail in jtreg.
> 
> The check itself isn't necessary within jtreg and that version check should instead reside as a regression test within the JDK repo. In fact there's already a regression test in JDK which catches these issues related to incorrect os.version reporting. Having this check in jtreg (that too only for macOS) prevents the tool from being used on these newer versions of macOS. In fact, jtreg itself cannot be built (with JDK 17) on macOS 26 (beta) due to this check.
> 
> The commit in this PR removes the check. I have run this change against macOS 26 (beta) where the tool would previously exit. The self-tests now all pass on that host:
> 
> 
> All (     234) selected tests completed successfully

Thank you Christian for the reivew. I'll go ahead and integrate this later in the day today.

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

PR Comment: https://git.openjdk.org/jtreg/pull/268#issuecomment-3002419625