From cstein at openjdk.org  Wed Mar  5 12:39:46 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 5 Mar 2025 12:39:46 GMT
Subject: RFR: 7903955: jtreg doesn't support .jasm in patch module [v3]
In-Reply-To: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
References: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
Message-ID: <RJnD7T0R_bZ3AoT-Z0pqa4m3Ktr1x6RmREK5W4ksioc=.11510ada-f125-437c-ab47-bd14bb2657d9@github.com>

> Please review this change to support compilation of `.jasm` in patched modules.
> 
> Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.

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

  Always run ModLibsTest targets

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/249/files
  - new: https://git.openjdk.org/jtreg/pull/249/files/a97f575c..6b52ff56

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

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

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

From jpai at openjdk.org  Wed Mar  5 12:51:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Mar 2025 12:51:23 GMT
Subject: RFR: 7903955: jtreg doesn't support .jasm in patch module [v3]
In-Reply-To: <RJnD7T0R_bZ3AoT-Z0pqa4m3Ktr1x6RmREK5W4ksioc=.11510ada-f125-437c-ab47-bd14bb2657d9@github.com>
References: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
 <RJnD7T0R_bZ3AoT-Z0pqa4m3Ktr1x6RmREK5W4ksioc=.11510ada-f125-437c-ab47-bd14bb2657d9@github.com>
Message-ID: <TsOKtCtQGeL08jYBMwNjwsNYvc2SBgdKpU1t0qgJzMc=.6407f02f-e01e-43e6-be59-be3eee2d75b6@github.com>

On Wed, 5 Mar 2025 12:39:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to support compilation of `.jasm` in patched modules.
>> 
>> Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Always run ModLibsTest targets

`ModLibsTest.gmk` requires a copyright year update.

Other than that, the change looks OK to me. But I don't have the necessary background about why there was a `module != null` check (which has now been removed in this PR) in this part of the code. My suggestion would be to wait for a few days to see if Jon @jonathan-gibbons has any inputs on the history or this change in general.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/249#pullrequestreview-2661010083

From cstein at openjdk.org  Wed Mar  5 13:35:44 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 5 Mar 2025 13:35:44 GMT
Subject: RFR: 7903955: jtreg doesn't support .jasm in patch module [v4]
In-Reply-To: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
References: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
Message-ID: <zfuv1Cy8St1Sgo054bsv-1vRWNfoeIM35LZ9nuU9UyY=.ecece9e7-9505-44b6-9f9f-35eed9f2adb4@github.com>

> Please review this change to support compilation of `.jasm` in patched modules.
> 
> Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.

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

  Update ModLibsTest.gmk

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/249/files
  - new: https://git.openjdk.org/jtreg/pull/249/files/6b52ff56..6bc67150

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

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

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

From jpai at openjdk.org  Wed Mar  5 13:47:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Mar 2025 13:47:05 GMT
Subject: RFR: 7903955: jtreg doesn't support .jasm in patch module [v4]
In-Reply-To: <zfuv1Cy8St1Sgo054bsv-1vRWNfoeIM35LZ9nuU9UyY=.ecece9e7-9505-44b6-9f9f-35eed9f2adb4@github.com>
References: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
 <zfuv1Cy8St1Sgo054bsv-1vRWNfoeIM35LZ9nuU9UyY=.ecece9e7-9505-44b6-9f9f-35eed9f2adb4@github.com>
Message-ID: <arWQslsnTWbXuy6VTW73yZuQvVLUzO_RVgBxR4-LgWE=.b2eabc2e-8e7e-4fdf-9018-9ac25f2b93fe@github.com>

On Wed, 5 Mar 2025 13:35:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to support compilation of `.jasm` in patched modules.
>> 
>> Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update ModLibsTest.gmk

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/249#pullrequestreview-2661158277

From a.silichenko at gmail.com  Wed Mar  5 17:45:39 2025
From: a.silichenko at gmail.com (Oleksii Sylichenko)
Date: Wed, 5 Mar 2025 19:45:39 +0200
Subject: Request for Assistance with Issues and PR Review for IDEA Plugin
Message-ID: <CACLiAdjmk16fagEAySi8-ZpDwWwkX19H_CojRbzEQt8eOcs=mQ@mail.gmail.com>

Hi JTReg Dev Community,

I hope this message finds you well.

I?ve recently created three pull requests for the IDEA plugin, addressing
some issues within the plugin. Unfortunately, I do not have the required
permissions to create issues in the bug tracking system, and I?m not sure
who I should reach out to in this regard.

I would like to kindly ask if someone could create the corresponding issues
for the bugs I?ve addressed, and if possible, review my pull requests. I
believe they can help improve the plugin and resolve some of the challenges
we?ve been facing.

Please let me know if anyone is available to assist with this, or if there
is someone specific I should contact directly for further actions.

Thank you in advance for your help, and I appreciate any feedback on my
pull requests.


   - Fix "Run Configuration" Window Freeze Issue:
   https://github.com/openjdk/jtreg/pull/250
   - Fix NPE in JTRegConfiguration.getJDKString:
   https://github.com/openjdk/jtreg/pull/251
   - Fix Launching Tests from Context Menu:
   https://github.com/openjdk/jtreg/pull/252



Best regards,
Oleksii Sylichenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jtreg-dev/attachments/20250305/0334d5a6/attachment.htm>

From duke at openjdk.org  Fri Mar  7 14:39:55 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 14:39:55 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation
Message-ID: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>

Update menu item location to open default settings window.

Current location is: `File -> New Projects Setup -> Settings for New Projects...`

Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".

![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)

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

Commit messages:
 - Update README.md

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

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

From jvernee at openjdk.org  Fri Mar  7 14:39:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Mar 2025 14:39:56 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation
In-Reply-To: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
Message-ID: <5xJvXh53HJXgf4vI4c81HpI8b-RhogdJRQLQEAEpVBI=.961c7c3f-c7ca-4651-bc01-89d5f4081e97@github.com>

On Thu, 6 Feb 2025 20:50:13 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Update menu item location to open default settings window.
> 
> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
> 
> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
> 
> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)

When I try this, I now see the `jtreg` settings under the 'Other Settings' tab: 
![image](https://github.com/user-attachments/assets/abd1fc00-5e68-4690-b970-e352cdd7208d)

I think this would also be useful to mention in the docs.

I've created https://bugs.openjdk.org/browse/CODETOOLS-7903962, Please change the title of the PR to:


7903962: Update IDEA plugin documentation

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

PR Comment: https://git.openjdk.org/jtreg/pull/247#issuecomment-2706581160
PR Comment: https://git.openjdk.org/jtreg/pull/247#issuecomment-2706594014

From duke at openjdk.org  Fri Mar  7 15:08:43 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 15:08:43 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v2]
In-Reply-To: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
Message-ID: <azU1oFPvseo0eRZmdK_ANa8r14n0dnYSqsDcJ0lSSWw=.8472bfd5-2d2c-4746-9a76-e21aa2c03969@github.com>

> Update menu item location to open default settings window.
> 
> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
> 
> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
> 
> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)

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

 - Merge branch 'openjdk:master' into idea-plugin-update-readme-default-settings
 - Update README.md
   
   Update menu item location to open default settings window.

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/247/files
  - new: https://git.openjdk.org/jtreg/pull/247/files/63805982..05f0fd2f

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

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

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

From duke at openjdk.org  Fri Mar  7 16:00:40 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 16:00:40 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v3]
In-Reply-To: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
Message-ID: <zjG-4VdmnEO5PYXBUpN6gN6z10d8wZAQpMJDB5qGET8=.c3da0cd1-2cc2-4a64-a346-68a20a03105a@github.com>

> Update menu item location to open default settings window.
> 
> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
> 
> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
> 
> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)

Oleksii Sylichenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Update README.md
  
  Update menu item location to open default settings window.

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

Changes: https://git.openjdk.org/jtreg/pull/247/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=247&range=02
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/247.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/247/head:pull/247

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

From duke at openjdk.org  Fri Mar  7 16:07:23 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 16:07:23 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v4]
In-Reply-To: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
Message-ID: <gYq-sFSZEm218LJE4PoHyx44eX29AK_9jH43HcmRln0=.17a021c7-41c4-47a2-bfa9-cef216fa8ebf@github.com>

> Update menu item location to open default settings window.
> 
> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
> 
> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
> 
> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)

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:

  7903962: Update IDEA plugin documentation
  
  Update menu item location to open default settings window.

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/247/files
  - new: https://git.openjdk.org/jtreg/pull/247/files/63805982..67cdbe08

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

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

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

From duke at openjdk.org  Fri Mar  7 16:15:23 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 16:15:23 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v5]
In-Reply-To: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
Message-ID: <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>

> Update menu item location to open default settings window.
> 
> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
> 
> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
> 
> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)

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

  7903962: Update IDEA plugin documentation
  - insert "-" into "drop-down"
  - remove doubled "the"
  - add a mention of 'Other Settings' to the New Projects Settings section

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/247/files
  - new: https://git.openjdk.org/jtreg/pull/247/files/67cdbe08..16ab82dd

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

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

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

From duke at openjdk.org  Fri Mar  7 16:21:10 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 16:21:10 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation
In-Reply-To: <5xJvXh53HJXgf4vI4c81HpI8b-RhogdJRQLQEAEpVBI=.961c7c3f-c7ca-4651-bc01-89d5f4081e97@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
 <5xJvXh53HJXgf4vI4c81HpI8b-RhogdJRQLQEAEpVBI=.961c7c3f-c7ca-4651-bc01-89d5f4081e97@github.com>
Message-ID: <Vgo1aFIfKCtugxMx7BOKO2YQP8yj6IfJz9Iq_yeCBAA=.8ed0518a-0e39-46b5-a213-5f4d50821b15@github.com>

On Fri, 7 Mar 2025 14:30:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Update menu item location to open default settings window.
>> 
>> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
>> 
>> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
>> 
>> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)
>
> I've created https://bugs.openjdk.org/browse/CODETOOLS-7903962, Please change the title of the PR to:
> 
> 
> 7903962: Update IDEA plugin documentation

@JornVernee, thank you for creating the issue. I have added a mention about 'Other Settings'.

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

PR Comment: https://git.openjdk.org/jtreg/pull/247#issuecomment-2706870239

From jvernee at openjdk.org  Fri Mar  7 16:23:19 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Mar 2025 16:23:19 GMT
Subject: RFR: 7903964: Fix NPE in JTRegConfiguration.getJDKString
In-Reply-To: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
References: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
Message-ID: <eFDViGNTVgeNNv1V9GfFzOEOh9ARQVaxPiQ6qVn0QNw=.bfb4a470-eb2c-4567-bfaa-635112745f91@github.com>

On Wed, 5 Mar 2025 16:47:50 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> # This bug appears when
> - The user removes the "Build" target from "Before launch" in the Run Configuration.
> - The user unsets or does not set the Project SDK, or if it has been removed from the file system.
> 
> # Steps to reproduce
> 
> 1. Open a JDK project.
> 2. Open "Project Structure".
> 3. Select an SDK in the Project tab.
> 4. Navigate to "Settings ? jtreg".
> 5. Set "JRE = "Default".
> 6. Run a test to automatically create a run configuration, or manually create one with "JRE = Default".
> 7. Open Project Structure again.
> 8. Set SDK = "&lt;No SDK&gt;".
> 9. Edit the previously created Run Configuration and remove the "Build" target from "Before launch".
> 10. Run the previously created Run Configuration.
> 
> ## Expected
> - Error message appeared: "No valid JDK configured for running jtreg tests"
> 
> ## Actual:
> - Nothing happened
> 
> # Implemented Changes
> 
> ## JTRegConfiguration.java
> - Add the `@NotNull` annotation to methods that are missing it but have it in the parent method.
> - Add javadoc to `getJDKString`.
> - Refactor `getJDKString`:
>   - Fix method getJDKString, to prevent NPE when Default SDK for the project was not set
> 
> ## JTRegConfigurationRunnableState.java
> - Change visibility to `public` to eliminate the warning in `JTRegConfiguration#getState`.

These changes look good, but please remove `final` from local variables here as well.

> Nothing happened

When I tested this, it was actually worse: the Run option was disabled entirely, and I had to restart the IDE to bring it back. I have created: [7903964](https://bugs.openjdk.org/browse/CODETOOLS-7903964) Please change the PR title to:


7903964: Fix NPE in JTRegConfiguration.getJDKString

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

PR Review: https://git.openjdk.org/jtreg/pull/251#pullrequestreview-2667615169
PR Comment: https://git.openjdk.org/jtreg/pull/251#issuecomment-2706706233

From duke at openjdk.org  Fri Mar  7 16:23:19 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 16:23:19 GMT
Subject: RFR: 7903964: Fix NPE in JTRegConfiguration.getJDKString
Message-ID: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>

# This bug appears when
- The user removes the "Build" target from "Before launch" in the Run Configuration.
- The user unsets or does not set the Project SDK, or if it has been removed from the file system.

# Steps to reproduce

1. Open a JDK project.
2. Open "Project Structure".
3. Select an SDK in the Project tab.
4. Navigate to "Settings ? jtreg".
5. Set "JRE = "Default".
6. Run a test to automatically create a run configuration, or manually create one with "JRE = Default".
7. Open Project Structure again.
8. Set SDK = "&lt;No SDK&gt;".
9. Edit the previously created Run Configuration and remove the "Build" target from "Before launch".
10. Run the previously created Run Configuration.

## Expected
- Error message appeared: "No valid JDK configured for running jtreg tests"

## Actual:
- Nothing happened

# Implemented Changes

## JTRegConfiguration.java
- Add the `@NotNull` annotation to methods that are missing it but have it in the parent method.
- Add javadoc to `getJDKString`.
- Refactor `getJDKString`:
  - Fix method getJDKString, to prevent NPE when Default SDK for the project was not set

## JTRegConfigurationRunnableState.java
- Change visibility to `public` to eliminate the warning in `JTRegConfiguration#getState`.

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

Commit messages:
 - JTRegConfigurationRunnableState.java:
 - JTRegConfiguration.java:

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

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

From jvernee at openjdk.org  Fri Mar  7 16:27:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Mar 2025 16:27:14 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v5]
In-Reply-To: <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
 <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
Message-ID: <3_0WdqNaWiLP31GAt6DeNewlz5Bf3xSrzqIRkgKxfJQ=.9fb04307-4887-47fd-afa7-781f3a07e742@github.com>

On Fri, 7 Mar 2025 16:15:23 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Update menu item location to open default settings window.
>> 
>> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
>> 
>> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
>> 
>> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903962: Update IDEA plugin documentation
>   - insert "-" into "drop-down"
>   - remove doubled "the"
>   - add a mention of 'Other Settings' to the New Projects Settings section

Marked as reviewed by jvernee (Committer).

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

PR Review: https://git.openjdk.org/jtreg/pull/247#pullrequestreview-2667764113

From jvernee at openjdk.org  Fri Mar  7 16:30:09 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Mar 2025 16:30:09 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v5]
In-Reply-To: <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
 <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
Message-ID: <nzFADsEe0RTeMn6DTtn4dW3mq8_Ezgxa-vGwCwDD8Ts=.dcb6400a-26cb-4ad2-8c9c-cb916dd5ece8@github.com>

On Fri, 7 Mar 2025 16:15:23 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Update menu item location to open default settings window.
>> 
>> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
>> 
>> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
>> 
>> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903962: Update IDEA plugin documentation
>   - insert "-" into "drop-down"
>   - remove doubled "the"
>   - add a mention of 'Other Settings' to the New Projects Settings section

I have asked someone with the Reviewer role in the code tools project to take a look as well, as I can not give final approval.

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

PR Comment: https://git.openjdk.org/jtreg/pull/247#issuecomment-2706889525

From cstein at openjdk.org  Fri Mar  7 16:35:10 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 7 Mar 2025 16:35:10 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v5]
In-Reply-To: <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
 <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
Message-ID: <VQV25U6cddgmxvdf8XLA_V4Edrx8Fx9_DuFiW-VrRxM=.671fb8cf-c18e-410c-8188-667763a61f27@github.com>

On Fri, 7 Mar 2025 16:15:23 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Update menu item location to open default settings window.
>> 
>> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
>> 
>> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
>> 
>> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903962: Update IDEA plugin documentation
>   - insert "-" into "drop-down"
>   - remove doubled "the"
>   - add a mention of 'Other Settings' to the New Projects Settings section

Marked as reviewed by cstein (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/247#pullrequestreview-2667780799

From duke at openjdk.org  Fri Mar  7 16:51:27 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 16:51:27 GMT
Subject: RFR: 7903964: Fix NPE in JTRegConfiguration.getJDKString [v2]
In-Reply-To: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
References: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
Message-ID: <ggDCFvdxzi-ebI5V370vsHvW8blqP0Bxm4jN233Ypvs=.8d045068-f7b3-477f-93b5-aa88eb4a3960@github.com>

> # This bug appears when
> - The user removes the "Build" target from "Before launch" in the Run Configuration.
> - The user unsets or does not set the Project SDK, or if it has been removed from the file system.
> 
> # Steps to reproduce
> 
> 1. Open a JDK project.
> 2. Open "Project Structure".
> 3. Select an SDK in the Project tab.
> 4. Navigate to "Settings ? jtreg".
> 5. Set "JRE = "Default".
> 6. Run a test to automatically create a run configuration, or manually create one with "JRE = Default".
> 7. Open Project Structure again.
> 8. Set SDK = "&lt;No SDK&gt;".
> 9. Edit the previously created Run Configuration and remove the "Build" target from "Before launch".
> 10. Run the previously created Run Configuration.
> 
> ## Expected
> - Error message appeared: "No valid JDK configured for running jtreg tests"
> 
> ## Actual:
> - Nothing happened
> 
> # Implemented Changes
> 
> ## JTRegConfiguration.java
> - Add the `@NotNull` annotation to methods that are missing it but have it in the parent method.
> - Add javadoc to `getJDKString`.
> - Refactor `getJDKString`:
>   - Fix method getJDKString, to prevent NPE when Default SDK for the project was not set
> 
> ## JTRegConfigurationRunnableState.java
> - Change visibility to `public` to eliminate the warning in `JTRegConfiguration#getState`.

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

  7903964: Fix NPE in JTRegConfiguration.getJDKString
  - remove `final` from local variables

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/251/files
  - new: https://git.openjdk.org/jtreg/pull/251/files/95271cb0..c0ade713

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

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

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

From duke at openjdk.org  Fri Mar  7 16:54:09 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 16:54:09 GMT
Subject: RFR: 7903964: Fix NPE in JTRegConfiguration.getJDKString
In-Reply-To: <eFDViGNTVgeNNv1V9GfFzOEOh9ARQVaxPiQ6qVn0QNw=.bfb4a470-eb2c-4567-bfaa-635112745f91@github.com>
References: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
 <eFDViGNTVgeNNv1V9GfFzOEOh9ARQVaxPiQ6qVn0QNw=.bfb4a470-eb2c-4567-bfaa-635112745f91@github.com>
Message-ID: <_KlejpNJAoOht19h32Hf6HVynKj2MwCHRcfOjty_pW4=.2affd3ed-a9d2-4b69-a535-b9e14c847950@github.com>

On Fri, 7 Mar 2025 15:14:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> # This bug appears when
>> - The user removes the "Build" target from "Before launch" in the Run Configuration.
>> - The user unsets or does not set the Project SDK, or if it has been removed from the file system.
>> 
>> # Steps to reproduce
>> 
>> 1. Open a JDK project.
>> 2. Open "Project Structure".
>> 3. Select an SDK in the Project tab.
>> 4. Navigate to "Settings ? jtreg".
>> 5. Set "JRE = "Default".
>> 6. Run a test to automatically create a run configuration, or manually create one with "JRE = Default".
>> 7. Open Project Structure again.
>> 8. Set SDK = "&lt;No SDK&gt;".
>> 9. Edit the previously created Run Configuration and remove the "Build" target from "Before launch".
>> 10. Run the previously created Run Configuration.
>> 
>> ## Expected
>> - Error message appeared: "No valid JDK configured for running jtreg tests"
>> 
>> ## Actual:
>> - Nothing happened
>> 
>> # Implemented Changes
>> 
>> ## JTRegConfiguration.java
>> - Add the `@NotNull` annotation to methods that are missing it but have it in the parent method.
>> - Add javadoc to `getJDKString`.
>> - Refactor `getJDKString`:
>>   - Fix method getJDKString, to prevent NPE when Default SDK for the project was not set
>> 
>> ## JTRegConfigurationRunnableState.java
>> - Change visibility to `public` to eliminate the warning in `JTRegConfiguration#getState`.
>
>> Nothing happened
> 
> When I tested this, it was actually worse: the Run option was disabled entirely, and I had to restart the IDE to bring it back. I have created: [7903964](https://bugs.openjdk.org/browse/CODETOOLS-7903964) Please change the PR title to:
> 
> 
> 7903964: Fix NPE in JTRegConfiguration.getJDKString

@JornVernee, thank you for creating the issue. I have removed "final" from the local variables.

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

PR Comment: https://git.openjdk.org/jtreg/pull/251#issuecomment-2706940637

From jvernee at openjdk.org  Fri Mar  7 17:09:10 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Mar 2025 17:09:10 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v5]
In-Reply-To: <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
 <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
Message-ID: <nzLXJTJNhScyoK2BNB7gXxA8M3K3y7wcCjmpIFqt2HY=.a5caa201-6077-428e-951e-a3e289db470a@github.com>

On Fri, 7 Mar 2025 16:15:23 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Update menu item location to open default settings window.
>> 
>> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
>> 
>> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
>> 
>> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903962: Update IDEA plugin documentation
>   - insert "-" into "drop-down"
>   - remove doubled "the"
>   - add a mention of 'Other Settings' to the New Projects Settings section

This PR is ready to be merged now. See the comment here for the instructions: https://github.com/openjdk/jtreg/pull/247#issuecomment-2640984455

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

PR Comment: https://git.openjdk.org/jtreg/pull/247#issuecomment-2706972217

From jvernee at openjdk.org  Fri Mar  7 17:10:05 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Mar 2025 17:10:05 GMT
Subject: RFR: 7903964: Fix NPE in JTRegConfiguration.getJDKString [v2]
In-Reply-To: <ggDCFvdxzi-ebI5V370vsHvW8blqP0Bxm4jN233Ypvs=.8d045068-f7b3-477f-93b5-aa88eb4a3960@github.com>
References: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
 <ggDCFvdxzi-ebI5V370vsHvW8blqP0Bxm4jN233Ypvs=.8d045068-f7b3-477f-93b5-aa88eb4a3960@github.com>
Message-ID: <3__6AllYGSWag-5srM1f9eDPYK5QLTy2fdgJlboy7d8=.65bcbc69-0776-4f8d-89bd-3c699b769b63@github.com>

On Fri, 7 Mar 2025 16:51:27 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> # This bug appears when
>> - The user removes the "Build" target from "Before launch" in the Run Configuration.
>> - The user unsets or does not set the Project SDK, or if it has been removed from the file system.
>> 
>> # Steps to reproduce
>> 
>> 1. Open a JDK project.
>> 2. Open "Project Structure".
>> 3. Select an SDK in the Project tab.
>> 4. Navigate to "Settings ? jtreg".
>> 5. Set "JRE = "Default".
>> 6. Run a test to automatically create a run configuration, or manually create one with "JRE = Default".
>> 7. Open Project Structure again.
>> 8. Set SDK = "&lt;No SDK&gt;".
>> 9. Edit the previously created Run Configuration and remove the "Build" target from "Before launch".
>> 10. Run the previously created Run Configuration.
>> 
>> ## Expected
>> - Error message appeared: "No valid JDK configured for running jtreg tests"
>> 
>> ## Actual:
>> - Nothing happened
>> 
>> # Implemented Changes
>> 
>> ## JTRegConfiguration.java
>> - Add the `@NotNull` annotation to methods that are missing it but have it in the parent method.
>> - Add javadoc to `getJDKString`.
>> - Refactor `getJDKString`:
>>   - Fix method getJDKString, to prevent NPE when Default SDK for the project was not set
>> 
>> ## JTRegConfigurationRunnableState.java
>> - Change visibility to `public` to eliminate the warning in `JTRegConfiguration#getState`.
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903964: Fix NPE in JTRegConfiguration.getJDKString
>   - remove `final` from local variables

Marked as reviewed by jvernee (Committer).

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

PR Review: https://git.openjdk.org/jtreg/pull/251#pullrequestreview-2667860279

From cstein at openjdk.org  Fri Mar  7 17:10:05 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 7 Mar 2025 17:10:05 GMT
Subject: RFR: 7903964: Fix NPE in JTRegConfiguration.getJDKString [v2]
In-Reply-To: <ggDCFvdxzi-ebI5V370vsHvW8blqP0Bxm4jN233Ypvs=.8d045068-f7b3-477f-93b5-aa88eb4a3960@github.com>
References: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
 <ggDCFvdxzi-ebI5V370vsHvW8blqP0Bxm4jN233Ypvs=.8d045068-f7b3-477f-93b5-aa88eb4a3960@github.com>
Message-ID: <ef_MIPzP6St4ZE9DtmL1_BI9DFEwGI-TqE3Mcb-iHao=.ee0fbe7b-0663-4b94-8552-008566f7cef7@github.com>

On Fri, 7 Mar 2025 16:51:27 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> # This bug appears when
>> - The user removes the "Build" target from "Before launch" in the Run Configuration.
>> - The user unsets or does not set the Project SDK, or if it has been removed from the file system.
>> 
>> # Steps to reproduce
>> 
>> 1. Open a JDK project.
>> 2. Open "Project Structure".
>> 3. Select an SDK in the Project tab.
>> 4. Navigate to "Settings ? jtreg".
>> 5. Set "JRE = "Default".
>> 6. Run a test to automatically create a run configuration, or manually create one with "JRE = Default".
>> 7. Open Project Structure again.
>> 8. Set SDK = "&lt;No SDK&gt;".
>> 9. Edit the previously created Run Configuration and remove the "Build" target from "Before launch".
>> 10. Run the previously created Run Configuration.
>> 
>> ## Expected
>> - Error message appeared: "No valid JDK configured for running jtreg tests"
>> 
>> ## Actual:
>> - Nothing happened
>> 
>> # Implemented Changes
>> 
>> ## JTRegConfiguration.java
>> - Add the `@NotNull` annotation to methods that are missing it but have it in the parent method.
>> - Add javadoc to `getJDKString`.
>> - Refactor `getJDKString`:
>>   - Fix method getJDKString, to prevent NPE when Default SDK for the project was not set
>> 
>> ## JTRegConfigurationRunnableState.java
>> - Change visibility to `public` to eliminate the warning in `JTRegConfiguration#getState`.
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903964: Fix NPE in JTRegConfiguration.getJDKString
>   - remove `final` from local variables

Marked as reviewed by cstein (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/251#pullrequestreview-2667864616

From jvernee at openjdk.org  Fri Mar  7 17:17:43 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Mar 2025 17:17:43 GMT
Subject: RFR: 7903963: Fix "Run Configuration" Window Freeze Issue
In-Reply-To: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
References: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
Message-ID: <O3Aswj_Asf5B2SeupN_iJFptna2Mb6-z5IOi2PT2toM=.75981073-cf80-4fe0-a96f-2a2d2fcb8d39@github.com>

On Wed, 5 Mar 2025 16:15:46 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> # When the Problem Occurs
> 
> The JTReg "Run Configuration" window freezes when the user selects a JRE that is not present in the project's SDK list.
> 
> # Why the Problem Occurs
> 
> There is a method `applyEditorTo` in the `JTRegConfigurable.java` class, which is called repeatedly while the "Run Configuration" window is open. Within this method, the method `jrePathEditor.getJrePathOrName()` is invoked. As a result, when this method is called for a JRE path not listed in IDEA, it attempts to determine the Java version. If the user has selected a raw JDK image, a Java process is launched, and the version is obtained from the process output (see [org.jetbrains.jps.model.java.impl.JdkVersionDetectorImpl#detectJdkVersionInfo](https://github.com/JetBrains/intellij-community/blob/baba77ecf93f44a2ccb34e5b206e03c60817d511/jps/model-impl/src/org/jetbrains/jps/model/java/impl/JdkVersionDetectorImpl.java#L40)). 
> 
> This call is too resource-intensive to be executed on the UI thread, causing the window to freeze.
> 
> # Steps to reproduce
> 
> 1. Open a JDK project.  
> 2. Open the "Project Structure" window.  
> 3. Navigate to "Platform Settings ? SDKs".
> 4. Remove the JDK that is used as the JRE for tests, or create a copy of this JDK on your file system.  
> 5. Create a new "JTReg Run Configuration".  
> 6. In the "JRE" field, select a JDK path that is not present in the Project SDK list (either the removed JDK or the copied one).  
> 
> ## Actual result
> - The window starts freezing, even after saving and reopening it.
> 
> # Implemented Changes
> 
> ## JTRegConfigurable.java
> - Fix Javadoc for the class.
> - Remove unused class field: `jtregDir`.
> - Add Javadoc to the methods: `createUIComponents`, `applyEditorTo`, `resetEditorFrom`
> - Fix window freeze caused by `jrePathEditor` in the method `applyEditorTo`.
> - Add method `applyEditorJrePathTo` to optimize data retrieval from `jrePathEditor`.
> 
> Since I implemented changes in this file, I also took the opportunity to clean up the code a bit.

> Hi, I?ve created this pull request, but I don?t have the necessary permissions to create an issue for it. Could someone please create an issue to track this change? I?m not sure who to contact directly, so any help would be appreciated.

Typically your best bet is to send a message to one of the mailing lists: https://mail.openjdk.org/mailman/listinfo For this plugin, the right list would be ide-support-dev at openjdk.org or jtreg-dev at openjdk.org

For now I'll make a JBS issue for you.

I was able to reproduce the issue. I noticed that is was particularly noticeable when I select the JRE field, and then select another field. The UI seems to freeze for 1-2 seconds. Thank you for the excellent reproduction steps!

I've created the issue: https://bugs.openjdk.org/browse/CODETOOLS-7903963 Please change the PR title to:


7903963: Fix "Run Configuration" Window Freeze Issue

I've verified that the fix works on my machine as well.

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/ui/JTRegConfigurable.java line 147:

> 145: 
> 146:         final String alternativeJrePath;
> 147:         final boolean alternativeJREPathEnabled;

I've discussed with my colleague, and in general we'd like to not have `final` on local variables, as it doesn't really add much value, but does introduce extra visual clutter. I know some parts of the plugin don't follow that rule, but we shouldn't add more of it.

Please remove `final` from local variables.

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/ui/JTRegConfigurable.java line 156:

> 154:             if (JdkUtil.checkForJdk(alternativeJrePath)) {
> 155:                 // If the path is a valid JDK, add it to the ComboBox list.
> 156:                 jrePathEditor.setPathOrName(alternativeJrePath, true);

I'd like to better understand the effect that adding the path to the list is intended to have. I think the main point here is that the next time `applyEditorTo` is called, the path will be in the list, and we will take the `if` branch instead, which at that point is faster?

The custom JRE path doesn't seem to persist if I close and re-open the run configuration dialogue.

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

PR Comment: https://git.openjdk.org/jtreg/pull/250#issuecomment-2706582009
PR Comment: https://git.openjdk.org/jtreg/pull/250#issuecomment-2706615051
PR Comment: https://git.openjdk.org/jtreg/pull/250#issuecomment-2706665129
PR Review Comment: https://git.openjdk.org/jtreg/pull/250#discussion_r1985265885
PR Review Comment: https://git.openjdk.org/jtreg/pull/250#discussion_r1985217532

From duke at openjdk.org  Fri Mar  7 17:17:43 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 17:17:43 GMT
Subject: RFR: 7903963: Fix "Run Configuration" Window Freeze Issue
Message-ID: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>

# When the Problem Occurs

The JTReg "Run Configuration" window freezes when the user selects a JRE that is not present in the project's SDK list.

# Why the Problem Occurs

There is a method `applyEditorTo` in the `JTRegConfigurable.java` class, which is called repeatedly while the "Run Configuration" window is open. Within this method, the method `jrePathEditor.getJrePathOrName()` is invoked. As a result, when this method is called for a JRE path not listed in IDEA, it attempts to determine the Java version. If the user has selected a raw JDK image, a Java process is launched, and the version is obtained from the process output (see [org.jetbrains.jps.model.java.impl.JdkVersionDetectorImpl#detectJdkVersionInfo](https://github.com/JetBrains/intellij-community/blob/baba77ecf93f44a2ccb34e5b206e03c60817d511/jps/model-impl/src/org/jetbrains/jps/model/java/impl/JdkVersionDetectorImpl.java#L40)). 

This call is too resource-intensive to be executed on the UI thread, causing the window to freeze.

# Steps to reproduce

1. Open a JDK project.  
2. Open the "Project Structure" window.  
3. Navigate to "Platform Settings ? SDKs".
4. Remove the JDK that is used as the JRE for tests, or create a copy of this JDK on your file system.  
5. Create a new "JTReg Run Configuration".  
6. In the "JRE" field, select a JDK path that is not present in the Project SDK list (either the removed JDK or the copied one).  

## Actual result
- The window starts freezing, even after saving and reopening it.

# Implemented Changes

## JTRegConfigurable.java
- Fix Javadoc for the class.
- Remove unused class field: `jtregDir`.
- Add Javadoc to the methods: `createUIComponents`, `applyEditorTo`, `resetEditorFrom`
- Fix window freeze caused by `jrePathEditor` in the method `applyEditorTo`.
- Add method `applyEditorJrePathTo` to optimize data retrieval from `jrePathEditor`.

Since I implemented changes in this file, I also took the opportunity to clean up the code a bit.

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

Commit messages:
 - JTRegConfigurable.java:

Changes: https://git.openjdk.org/jtreg/pull/250/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=250&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903963
  Stats: 78 lines in 1 file changed: 71 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jtreg/pull/250.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/250/head:pull/250

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

From duke at openjdk.org  Fri Mar  7 17:17:43 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 17:17:43 GMT
Subject: RFR: 7903963: Fix "Run Configuration" Window Freeze Issue
In-Reply-To: <O3Aswj_Asf5B2SeupN_iJFptna2Mb6-z5IOi2PT2toM=.75981073-cf80-4fe0-a96f-2a2d2fcb8d39@github.com>
References: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
 <O3Aswj_Asf5B2SeupN_iJFptna2Mb6-z5IOi2PT2toM=.75981073-cf80-4fe0-a96f-2a2d2fcb8d39@github.com>
Message-ID: <CesaMqfEqxfPqp4Ml-juwKgBjsfPOOGj5crxZFA6c3I=.65e4fe11-2f81-4f66-9358-209ff1f3b631@github.com>

On Fri, 7 Mar 2025 14:58:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> # When the Problem Occurs
>> 
>> The JTReg "Run Configuration" window freezes when the user selects a JRE that is not present in the project's SDK list.
>> 
>> # Why the Problem Occurs
>> 
>> There is a method `applyEditorTo` in the `JTRegConfigurable.java` class, which is called repeatedly while the "Run Configuration" window is open. Within this method, the method `jrePathEditor.getJrePathOrName()` is invoked. As a result, when this method is called for a JRE path not listed in IDEA, it attempts to determine the Java version. If the user has selected a raw JDK image, a Java process is launched, and the version is obtained from the process output (see [org.jetbrains.jps.model.java.impl.JdkVersionDetectorImpl#detectJdkVersionInfo](https://github.com/JetBrains/intellij-community/blob/baba77ecf93f44a2ccb34e5b206e03c60817d511/jps/model-impl/src/org/jetbrains/jps/model/java/impl/JdkVersionDetectorImpl.java#L40)). 
>> 
>> This call is too resource-intensive to be executed on the UI thread, causing the window to freeze.
>> 
>> # Steps to reproduce
>> 
>> 1. Open a JDK project.  
>> 2. Open the "Project Structure" window.  
>> 3. Navigate to "Platform Settings ? SDKs".
>> 4. Remove the JDK that is used as the JRE for tests, or create a copy of this JDK on your file system.  
>> 5. Create a new "JTReg Run Configuration".  
>> 6. In the "JRE" field, select a JDK path that is not present in the Project SDK list (either the removed JDK or the copied one).  
>> 
>> ## Actual result
>> - The window starts freezing, even after saving and reopening it.
>> 
>> # Implemented Changes
>> 
>> ## JTRegConfigurable.java
>> - Fix Javadoc for the class.
>> - Remove unused class field: `jtregDir`.
>> - Add Javadoc to the methods: `createUIComponents`, `applyEditorTo`, `resetEditorFrom`
>> - Fix window freeze caused by `jrePathEditor` in the method `applyEditorTo`.
>> - Add method `applyEditorJrePathTo` to optimize data retrieval from `jrePathEditor`.
>> 
>> Since I implemented changes in this file, I also took the opportunity to clean up the code a bit.
>
> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/ui/JTRegConfigurable.java line 156:
> 
>> 154:             if (JdkUtil.checkForJdk(alternativeJrePath)) {
>> 155:                 // If the path is a valid JDK, add it to the ComboBox list.
>> 156:                 jrePathEditor.setPathOrName(alternativeJrePath, true);
> 
> I'd like to better understand the effect that adding the path to the list is intended to have. I think the main point here is that the next time `applyEditorTo` is called, the path will be in the list, and we will take the `if` branch instead, which at that point is faster?
> 
> The custom JRE path doesn't seem to persist if I close and re-open the run configuration dialogue.

Yes, this is so that the next time `applyEditorTo` is called, we can safely call `jrePathEditor.getJrePathOrName()` and `jrePathEditor.isAlternativeJreSelected()` (the `if` case).

The custom JRE path does indeed only exist in the list while the window is open.
I added this code to ensure that in the general case, the original `getJrePathOrName` and `isAlternativeJreSelected` calls are used.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/250#discussion_r1985419408

From duke at openjdk.org  Fri Mar  7 17:30:19 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 17:30:19 GMT
Subject: RFR: 7903963: Fix "Run Configuration" Window Freeze Issue [v2]
In-Reply-To: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
References: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
Message-ID: <ZVZi0YaqvEqEBlifsII54c-3fT-ZI9EbrEVq2QVseQo=.60378641-0028-4d4c-ba5a-49180606120c@github.com>

> # When the Problem Occurs
> 
> The JTReg "Run Configuration" window freezes when the user selects a JRE that is not present in the project's SDK list.
> 
> # Why the Problem Occurs
> 
> There is a method `applyEditorTo` in the `JTRegConfigurable.java` class, which is called repeatedly while the "Run Configuration" window is open. Within this method, the method `jrePathEditor.getJrePathOrName()` is invoked. As a result, when this method is called for a JRE path not listed in IDEA, it attempts to determine the Java version. If the user has selected a raw JDK image, a Java process is launched, and the version is obtained from the process output (see [org.jetbrains.jps.model.java.impl.JdkVersionDetectorImpl#detectJdkVersionInfo](https://github.com/JetBrains/intellij-community/blob/baba77ecf93f44a2ccb34e5b206e03c60817d511/jps/model-impl/src/org/jetbrains/jps/model/java/impl/JdkVersionDetectorImpl.java#L40)). 
> 
> This call is too resource-intensive to be executed on the UI thread, causing the window to freeze.
> 
> # Steps to reproduce
> 
> 1. Open a JDK project.  
> 2. Open the "Project Structure" window.  
> 3. Navigate to "Platform Settings ? SDKs".
> 4. Remove the JDK that is used as the JRE for tests, or create a copy of this JDK on your file system.  
> 5. Create a new "JTReg Run Configuration".  
> 6. In the "JRE" field, select a JDK path that is not present in the Project SDK list (either the removed JDK or the copied one).  
> 
> ## Actual result
> - The window starts freezing, even after saving and reopening it.
> 
> # Implemented Changes
> 
> ## JTRegConfigurable.java
> - Fix Javadoc for the class.
> - Remove unused class field: `jtregDir`.
> - Add Javadoc to the methods: `createUIComponents`, `applyEditorTo`, `resetEditorFrom`
> - Fix window freeze caused by `jrePathEditor` in the method `applyEditorTo`.
> - Add method `applyEditorJrePathTo` to optimize data retrieval from `jrePathEditor`.
> 
> Since I implemented changes in this file, I also took the opportunity to clean up the code a bit.

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

  7903963: Fix "Run Configuration" Window Freeze Issue
  - remove `final` from local variables

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/250/files
  - new: https://git.openjdk.org/jtreg/pull/250/files/72179e86..dac43fe4

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

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

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

From duke at openjdk.org  Fri Mar  7 17:30:19 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 7 Mar 2025 17:30:19 GMT
Subject: RFR: 7903963: Fix "Run Configuration" Window Freeze Issue [v2]
In-Reply-To: <O3Aswj_Asf5B2SeupN_iJFptna2Mb6-z5IOi2PT2toM=.75981073-cf80-4fe0-a96f-2a2d2fcb8d39@github.com>
References: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
 <O3Aswj_Asf5B2SeupN_iJFptna2Mb6-z5IOi2PT2toM=.75981073-cf80-4fe0-a96f-2a2d2fcb8d39@github.com>
Message-ID: <yIIeIh4alc5JKI1nOcm8cmLsBhuQnrHHeAOz0jzgiTU=.a21994bb-bd0a-44b3-a206-097578cec3ce@github.com>

On Fri, 7 Mar 2025 15:29:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   7903963: Fix "Run Configuration" Window Freeze Issue
>>   - remove `final` from local variables
>
> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/ui/JTRegConfigurable.java line 147:
> 
>> 145: 
>> 146:         final String alternativeJrePath;
>> 147:         final boolean alternativeJREPathEnabled;
> 
> I've discussed with my colleague, and in general we'd like to not have `final` on local variables, as it doesn't really add much value, but does introduce extra visual clutter. I know some parts of the plugin don't follow that rule, but we shouldn't add more of it.
> 
> Please remove `final` from local variables.

done

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/250#discussion_r1985437185

From duke at openjdk.org  Fri Mar  7 17:37:06 2025
From: duke at openjdk.org (duke)
Date: Fri, 7 Mar 2025 17:37:06 GMT
Subject: RFR: 7903962: Update IDEA plugin documentation [v5]
In-Reply-To: <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
 <h60TltoDddQKdP3aM-zR2mu8VxwBfCbmtDGZmF5exEg=.b3094865-485e-49fa-96b6-0f9c5887939c@github.com>
Message-ID: <Kc5FTayymQ2Gn4mUDuKaG2PzCFZC0lXCmJt6BL_Ns7c=.55345d9e-e7c1-4b66-976a-d5ad6d1a952d@github.com>

On Fri, 7 Mar 2025 16:15:23 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Update menu item location to open default settings window.
>> 
>> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
>> 
>> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
>> 
>> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903962: Update IDEA plugin documentation
>   - insert "-" into "drop-down"
>   - remove doubled "the"
>   - add a mention of 'Other Settings' to the New Projects Settings section

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

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

PR Comment: https://git.openjdk.org/jtreg/pull/247#issuecomment-2707027350

From duke at openjdk.org  Fri Mar  7 17:39:08 2025
From: duke at openjdk.org (duke)
Date: Fri, 7 Mar 2025 17:39:08 GMT
Subject: RFR: 7903964: Fix NPE in JTRegConfiguration.getJDKString [v2]
In-Reply-To: <ggDCFvdxzi-ebI5V370vsHvW8blqP0Bxm4jN233Ypvs=.8d045068-f7b3-477f-93b5-aa88eb4a3960@github.com>
References: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
 <ggDCFvdxzi-ebI5V370vsHvW8blqP0Bxm4jN233Ypvs=.8d045068-f7b3-477f-93b5-aa88eb4a3960@github.com>
Message-ID: <jaPsw1LQIFe6heocGLYuCWQxNwa6zb_P_2C-TTlZti8=.350b053e-3ba0-4d7e-8d7a-5af65da285c4@github.com>

On Fri, 7 Mar 2025 16:51:27 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> # This bug appears when
>> - The user removes the "Build" target from "Before launch" in the Run Configuration.
>> - The user unsets or does not set the Project SDK, or if it has been removed from the file system.
>> 
>> # Steps to reproduce
>> 
>> 1. Open a JDK project.
>> 2. Open "Project Structure".
>> 3. Select an SDK in the Project tab.
>> 4. Navigate to "Settings ? jtreg".
>> 5. Set "JRE = "Default".
>> 6. Run a test to automatically create a run configuration, or manually create one with "JRE = Default".
>> 7. Open Project Structure again.
>> 8. Set SDK = "&lt;No SDK&gt;".
>> 9. Edit the previously created Run Configuration and remove the "Build" target from "Before launch".
>> 10. Run the previously created Run Configuration.
>> 
>> ## Expected
>> - Error message appeared: "No valid JDK configured for running jtreg tests"
>> 
>> ## Actual:
>> - Nothing happened
>> 
>> # Implemented Changes
>> 
>> ## JTRegConfiguration.java
>> - Add the `@NotNull` annotation to methods that are missing it but have it in the parent method.
>> - Add javadoc to `getJDKString`.
>> - Refactor `getJDKString`:
>>   - Fix method getJDKString, to prevent NPE when Default SDK for the project was not set
>> 
>> ## JTRegConfigurationRunnableState.java
>> - Change visibility to `public` to eliminate the warning in `JTRegConfiguration#getState`.
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903964: Fix NPE in JTRegConfiguration.getJDKString
>   - remove `final` from local variables

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

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

PR Comment: https://git.openjdk.org/jtreg/pull/251#issuecomment-2707029888

From duke at openjdk.org  Sat Mar  8 23:02:04 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Sat, 8 Mar 2025 23:02:04 GMT
Subject: Integrated: 7903962: Update IDEA plugin documentation
In-Reply-To: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
References: <k62GDNFvxA7GWR3FPvMT49B8Hkw8MBtsFkLhCE1j-qA=.bfc49853-4fd0-4546-8cd5-6f17f88dff0d@github.com>
Message-ID: <ju2YojGKxyaxwV3tKP8taqHiVBVB68Wh8yLy84_8Q4o=.507e8fd5-12e6-4b8a-aaf6-e884bc6dd2df@github.com>

On Thu, 6 Feb 2025 20:50:13 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Update menu item location to open default settings window.
> 
> Current location is: `File -> New Projects Setup -> Settings for New Projects...`
> 
> Checked in "IntelliJ IDEA 2024.3.2.2 (Community Edition)".
> 
> ![Default settings menu location](https://github.com/user-attachments/assets/e9b94e74-5bea-476f-bcb1-f75ce76f3fc2)

This pull request has now been integrated.

Changeset: 03c2ac63
Author:    Oleksii Sylichenko <a.silichenko at gmail.com>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/03c2ac63d7d5b47d1630faaf5951f13dcd807620
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

7903962: Update IDEA plugin documentation

Reviewed-by: jvernee, cstein

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

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

From duke at openjdk.org  Sat Mar  8 23:03:03 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Sat, 8 Mar 2025 23:03:03 GMT
Subject: Integrated: 7903964: Fix NPE in JTRegConfiguration.getJDKString
In-Reply-To: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
References: <_ZF6ug_RGapF9QAhy-ZJ7aAZ89whX6v6CgwTKFjgbJk=.0cbd8ede-52f8-47b1-a939-adcd6520c0b8@github.com>
Message-ID: <ojW10OWx-AFeGxoY6YkwCUsmggGXGIu0dfVjhbSZHIY=.92d8236b-b26d-4526-bb4b-212e6df0b189@github.com>

On Wed, 5 Mar 2025 16:47:50 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> # This bug appears when
> - The user removes the "Build" target from "Before launch" in the Run Configuration.
> - The user unsets or does not set the Project SDK, or if it has been removed from the file system.
> 
> # Steps to reproduce
> 
> 1. Open a JDK project.
> 2. Open "Project Structure".
> 3. Select an SDK in the Project tab.
> 4. Navigate to "Settings ? jtreg".
> 5. Set "JRE = "Default".
> 6. Run a test to automatically create a run configuration, or manually create one with "JRE = Default".
> 7. Open Project Structure again.
> 8. Set SDK = "&lt;No SDK&gt;".
> 9. Edit the previously created Run Configuration and remove the "Build" target from "Before launch".
> 10. Run the previously created Run Configuration.
> 
> ## Expected
> - Error message appeared: "No valid JDK configured for running jtreg tests"
> 
> ## Actual:
> - Nothing happened
> 
> # Implemented Changes
> 
> ## JTRegConfiguration.java
> - Add the `@NotNull` annotation to methods that are missing it but have it in the parent method.
> - Add javadoc to `getJDKString`.
> - Refactor `getJDKString`:
>   - Fix method getJDKString, to prevent NPE when Default SDK for the project was not set
> 
> ## JTRegConfigurationRunnableState.java
> - Change visibility to `public` to eliminate the warning in `JTRegConfiguration#getState`.

This pull request has now been integrated.

Changeset: a74be071
Author:    Oleksii Sylichenko <a.silichenko at gmail.com>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/a74be0712e7d4e617060ad9f3ed9719faa2f57e2
Stats:     31 lines in 2 files changed: 15 ins; 3 del; 13 mod

7903964: Fix NPE in JTRegConfiguration.getJDKString

Reviewed-by: jvernee, cstein

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

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

From cstein at openjdk.org  Mon Mar 10 10:28:22 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 10 Mar 2025 10:28:22 GMT
Subject: RFR: 7903961: Make default timeout configurable
Message-ID: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>

Please review this change replacing the hard-coded `120` seconds default timeout for test actions with a configurable solution parsing a custom default value from `TEST.ROOT` and `TEST.properties` files.

Especially in combination with "JUnit.dirs" and "TestNG.dirs", where all actions directives found in a test file are ignored, is helpful.

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

Commit messages:
 - Add tag-spec entry
 - Increase expected test pass count
 - 7903961: Make default timeout configurable

Changes: https://git.openjdk.org/jtreg/pull/253/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=253&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903961
  Stats: 88 lines in 7 files changed: 76 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jtreg/pull/253.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/253/head:pull/253

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

From jvernee at openjdk.org  Mon Mar 10 10:36:05 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Mar 2025 10:36:05 GMT
Subject: RFR: 7903963: Fix "Run Configuration" Window Freeze Issue [v2]
In-Reply-To: <ZVZi0YaqvEqEBlifsII54c-3fT-ZI9EbrEVq2QVseQo=.60378641-0028-4d4c-ba5a-49180606120c@github.com>
References: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
 <ZVZi0YaqvEqEBlifsII54c-3fT-ZI9EbrEVq2QVseQo=.60378641-0028-4d4c-ba5a-49180606120c@github.com>
Message-ID: <XmAQFbDWB2HWCcktVOwI2Z7hPWVxLVkafdl4jHcgFCQ=.e5029c3a-5f66-4446-9285-e9ac5f48c9da@github.com>

On Fri, 7 Mar 2025 17:30:19 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> # When the Problem Occurs
>> 
>> The JTReg "Run Configuration" window freezes when the user selects a JRE that is not present in the project's SDK list.
>> 
>> # Why the Problem Occurs
>> 
>> There is a method `applyEditorTo` in the `JTRegConfigurable.java` class, which is called repeatedly while the "Run Configuration" window is open. Within this method, the method `jrePathEditor.getJrePathOrName()` is invoked. As a result, when this method is called for a JRE path not listed in IDEA, it attempts to determine the Java version. If the user has selected a raw JDK image, a Java process is launched, and the version is obtained from the process output (see [org.jetbrains.jps.model.java.impl.JdkVersionDetectorImpl#detectJdkVersionInfo](https://github.com/JetBrains/intellij-community/blob/baba77ecf93f44a2ccb34e5b206e03c60817d511/jps/model-impl/src/org/jetbrains/jps/model/java/impl/JdkVersionDetectorImpl.java#L40)). 
>> 
>> This call is too resource-intensive to be executed on the UI thread, causing the window to freeze.
>> 
>> # Steps to reproduce
>> 
>> 1. Open a JDK project.  
>> 2. Open the "Project Structure" window.  
>> 3. Navigate to "Platform Settings ? SDKs".
>> 4. Remove the JDK that is used as the JRE for tests, or create a copy of this JDK on your file system.  
>> 5. Create a new "JTReg Run Configuration".  
>> 6. In the "JRE" field, select a JDK path that is not present in the Project SDK list (either the removed JDK or the copied one).  
>> 
>> ## Actual result
>> - The window starts freezing, even after saving and reopening it.
>> 
>> # Implemented Changes
>> 
>> ## JTRegConfigurable.java
>> - Fix Javadoc for the class.
>> - Remove unused class field: `jtregDir`.
>> - Add Javadoc to the methods: `createUIComponents`, `applyEditorTo`, `resetEditorFrom`
>> - Fix window freeze caused by `jrePathEditor` in the method `applyEditorTo`.
>> - Add method `applyEditorJrePathTo` to optimize data retrieval from `jrePathEditor`.
>> 
>> Since I implemented changes in this file, I also took the opportunity to clean up the code a bit.
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903963: Fix "Run Configuration" Window Freeze Issue
>   - remove `final` from local variables

Marked as reviewed by jvernee (Committer).

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

PR Review: https://git.openjdk.org/jtreg/pull/250#pullrequestreview-2670480525

From duke at openjdk.org  Mon Mar 10 12:59:48 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 12:59:48 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
Message-ID: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>

Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.

After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.

As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:

- Editor tab
- File in the project tree
- Directory in the project tree
- Any location within a file

The current changes automatically determine what needs to be executed:

- Directory
- File
- Method

Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.

# Summary

- Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
- Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
- Improve the logic for comparing existing run configurations with newly generated ones.  
- Add JUnit plugin in the dependencies.

# Detailed changes

## Add JUnit plugin into dependencies
- build.gradle
- plugin.xml

## JTRegClassConfigurationProducer.java
- Refactor `setupConfigurationFromContext`:
  - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
  - Allow this method to create configurations for directories as well.  
  - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
  - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
- Implement `preventRunPriorityLoss`.
- Add Javadoc for `nameForElement`.

## JTRegConfigurationProducer.java
- Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
  - Replace the use of the current PSI element for queries with the exact element intended for execution.  
- Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
- Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
- Add a JUnit check to the `shouldReplace` method.

## JTRegUtils.java
- Add a predicate to compare two strings using a "not-nullify" approach (`null == ""`).
- Add predicates to determine whether a PSI method or class is a TestNG or JUnit element.
- Add predicates to check if a PSI element is a file or a directory.
- Extract and refactor code from `JTRegClassConfigurationProducer.java` into a method `isRunnableByJTReg`.
- Simplified method "isInJTRegRoot" in order to remove code check warning.

# Testing the Current Changes

Here are the sample test files: [atest.zip](https://github.com/user-attachments/files/19093354/atest.zip)

I performed testing on the following cases.

### Type of test
- TestNG
- JUnit
- JTReg

### Position of right-mouse click
- Before class definition -> run class or file
- Class name -> run class or file
- Body of the class -> run class or file
- Not test method -> run class of file
- Test method (Regardless of how deeply the click was made within the internal structures of the method) -> run test method
- Nected class (JUnit) -> run nested class
- Test method in the nested class (JUnit) -> run test method of the nested class
- Static class (JUnit) -> run main class or file
- Common JUnit test: `org.junit.Test`
- Jupiter test: `org.junit.jupiter.api.Test`
- Data provider method (TestNG) -> run class or file
- Annotated method with ParameterizedTest (JUnit) -> run method
- All possible green arrows on the side field of the editor -> run configuration should correspond
- More than one class is present in the file -> plain extra classes should be ignored
- JTReg test contains "main" method -> always run file
- TestNG and JUnit test file without directive "@test" in the comments should not be run by JTReg

## Some examples from JDK

### TestNG
- test/langtools/jdk/jshell/ToolSimpleTest.java
- test/jdk/jdk/internal/util/ArraysSupport/NewLength.java
- test/langtools/jdk/jshell/AnalysisTest.java

### JUnit
- test/jdk/jdk/internal/util/VersionTest.java
- test/jdk/jdk/internal/util/OSTest.java
- test/jdk/java/util/Currency/CurrencyTest.java

### JTReg
- test/langtools/tools/javac/cast/BoxedArray.java
- test/langtools/tools/javac/4241573/T4241573.java

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

Commit messages:
 - Fix typo: "left" -> "rest of the"
 - Remove `final` from local variables
 - JTRegConfigurationProducer.java:
 - JTRegConfigurationProducer.java:
 - JTRegUtils.java:
 - JTRegUtils.java:
 - Add JUnit plugin into dependencies:

Changes: https://git.openjdk.org/jtreg/pull/252/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=252&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903965
  Stats: 239 lines in 5 files changed: 209 ins; 4 del; 26 mod
  Patch: https://git.openjdk.org/jtreg/pull/252.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/252/head:pull/252

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

From jvernee at openjdk.org  Mon Mar 10 12:59:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Mar 2025 12:59:52 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
Message-ID: <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>

On Wed, 5 Mar 2025 17:28:47 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
> 
> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
> 
> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
> 
> - Editor tab
> - File in the project tree
> - Directory in the project tree
> - Any location within a file
> 
> The current changes automatically determine what needs to be executed:
> 
> - Directory
> - File
> - Method
> 
> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> # Summary
> 
> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
> - Improve the logic for comparing existing run configurations with newly generated ones.  
> - Add JUnit plugin in the dependencies.
> 
> # Detailed changes
> 
> ## Add JUnit plugin into dependencies
> - build.gradle
> - plugin.xml
> 
> ## JTRegClassConfigurationProducer.java
> - Refactor `setupConfigurationFromContext`:
>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>   - Allow this method to create configurations for directories as well.  
>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
> - Implement `preventRunPriorityLoss`.
> - Add Javadoc for `nameForElement`.
> 
> ## JTRegConfigurationProducer.java
> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
> - Add a JUnit check to the `shouldReplace` method.
> 
> ## JTRegUtils.java
> - Add a predicate to compare two strings ...

I've created https://bugs.openjdk.org/browse/CODETOOLS-7903965 for this PR

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegClassConfigurationProducer.java line 73:

> 71:         if (element instanceof PsiDirectory runDir) {
> 72:             configuration.setPackage(runDir.getVirtualFile().getPath());
> 73:         } else {

If this producer can now handle directories too, do we still need `JTRegDirectoryConfigurationProducer`?

Also, for a directory this would end up calling `nameForElement` -> `element.getContainingFile().getName()`, where `getContainingFile` seemingly returns `null`, so I think that would fail.

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegClassConfigurationProducer.java line 125:

> 123:             }
> 124:         }
> 125:     }

> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.

I think this issue is addressed in this code here.

What are the steps to reproduce this issue? When I try to create a run configuration through the context menu on the editor tab, I seem to get a JTreg configuration every time. Or I get the option to choose one or the other: 
![image](https://github.com/user-attachments/assets/2a1abcf5-4e7d-45f8-a82e-9ea9d392a16a)

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 76:

> 74:         }
> 75: 
> 76:         final Location<?> location = JavaExecutionUtil.stepIntoSingleClass(contextLocation);

Suggestion:

        Location<?> location = JavaExecutionUtil.stepIntoSingleClass(contextLocation);

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 90:

> 88:         final String contextFilePath = null != contextVirtualFile ? contextVirtualFile.getPath() : null;
> 89: 
> 90:         final String contextDirPath = (element instanceof PsiDirectory d) ? d.getVirtualFile().getPath() : null;

Suggestion:

        String contextQuery = getQuery(element);

        PsiFile contextFile = (element instanceof PsiFile psiFile) ? psiFile : element.getContainingFile();
        VirtualFile contextVirtualFile = null != contextFile ? contextFile.getVirtualFile() : null;
        String contextFilePath = null != contextVirtualFile ? contextVirtualFile.getPath() : null;

        String contextDirPath = (element instanceof PsiDirectory d) ? d.getVirtualFile().getPath() : null;

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 128:

> 126: 
> 127:             if (IS_THIRD_PARTY_TEST_ELEMENT.test(e)) {
> 128:                 final PsiElement identifyingElement = ((PsiNameIdentifierOwner) e).getIdentifyingElement();

Suggestion:

                PsiElement identifyingElement = ((PsiNameIdentifierOwner) e).getIdentifyingElement();

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 131:

> 129:                 if (null != identifyingElement) { // null for name of the non-test inner class
> 130:                     if (null == retval) {
> 131:                         // When found, check the left hierarchy up to the class for runnability

Suggestion:

                        // When found, check the rest of the hierarchy up to the class for runnability

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 233:

> 231:     @Override
> 232:     public boolean shouldReplace(@NotNull ConfigurationFromContext self, @NotNull ConfigurationFromContext other) {
> 233:         final RunConfiguration otherCnf = other.getConfiguration();

Suggestion:

        RunConfiguration otherCnf = other.getConfiguration();

plugins/idea/src/main/java/com/oracle/plugin/jtreg/util/JTRegUtils.java line 94:

> 92:     public static final Predicate<PsiElement> IS_DIR_ELEMENT = PsiDirectory.class::isInstance;
> 93:     public static final Predicate<PsiElement> IS_FILE_ELEMENT = PsiFile.class::isInstance;
> 94:     public static final Predicate<PsiElement> IS_FILE_OR_DIR_ELEMENT = IS_FILE_ELEMENT.or(IS_DIR_ELEMENT);

Why are these all predicates? I'd much prefer a set of static methods. These predicates make the logic harder to follow.

plugins/idea/src/main/java/com/oracle/plugin/jtreg/util/JTRegUtils.java line 355:

> 353:     public static boolean isRunnableByJTReg(@NotNull PsiElement element) {
> 354:         final PsiFile runFile;
> 355:         final PsiDirectory runDir;

Suggestion:

        PsiFile runFile;
        PsiDirectory runDir;

plugins/idea/src/main/resources/META-INF/plugin.xml line 36:

> 34:     <depends>AntSupport</depends>
> 35:     <depends>TestNG-J</depends>
> 36:     <depends>JUnit</depends>

Is this required for `JUnitUtil` and `JUnitConfiguration`?

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

PR Comment: https://git.openjdk.org/jtreg/pull/252#issuecomment-2710465198
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987145313
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987159096
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987163320
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987163649
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987170313
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987170095
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987135751
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987168370
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987134337
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987132790

From duke at openjdk.org  Mon Mar 10 12:59:53 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 12:59:53 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
Message-ID: <tCQcyT_YP1CUbTUCF_Ob_bbSlmh0cI17EWo6NtJ4d8A=.2f3e37fd-1493-4eb1-a5bc-0ef5e58e26ce@github.com>

On Mon, 10 Mar 2025 12:08:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## JTRegClassConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> 
>> ## JTRegConfigurationProducer.java
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
>> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
>> - Add a JUnit chec...
>
> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegClassConfigurationProducer.java line 125:
> 
>> 123:             }
>> 124:         }
>> 125:     }
> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> I think this issue is addressed in this code here.
> 
> What are the steps to reproduce this issue? When I try to create a run configuration through the context menu on the editor tab, I seem to get a JTreg configuration every time. Or I get the option to choose one or the other: 
> ![image](https://github.com/user-attachments/assets/2a1abcf5-4e7d-45f8-a82e-9ea9d392a16a)

![test/jdk/java/foreign/TestSegmentBulkOperationsContentHash.java](https://github.com/user-attachments/assets/4db38b2a-9643-42df-a28b-01093f065424)

> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 76:
> 
>> 74:         }
>> 75: 
>> 76:         final Location<?> location = JavaExecutionUtil.stepIntoSingleClass(contextLocation);
> 
> Suggestion:
> 
>         Location<?> location = JavaExecutionUtil.stepIntoSingleClass(contextLocation);

finals have been already removed in the last commit (a1350eb9ed33e626ffeab2518f656b226e5a1b96)

> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 90:
> 
>> 88:         final String contextFilePath = null != contextVirtualFile ? contextVirtualFile.getPath() : null;
>> 89: 
>> 90:         final String contextDirPath = (element instanceof PsiDirectory d) ? d.getVirtualFile().getPath() : null;
> 
> Suggestion:
> 
>         String contextQuery = getQuery(element);
> 
>         PsiFile contextFile = (element instanceof PsiFile psiFile) ? psiFile : element.getContainingFile();
>         VirtualFile contextVirtualFile = null != contextFile ? contextFile.getVirtualFile() : null;
>         String contextFilePath = null != contextVirtualFile ? contextVirtualFile.getPath() : null;
> 
>         String contextDirPath = (element instanceof PsiDirectory d) ? d.getVirtualFile().getPath() : null;

finals have been already removed in the last commit (a1350eb9ed33e626ffeab2518f656b226e5a1b96)

> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 131:
> 
>> 129:                 if (null != identifyingElement) { // null for name of the non-test inner class
>> 130:                     if (null == retval) {
>> 131:                         // When found, check the left hierarchy up to the class for runnability
> 
> Suggestion:
> 
>                         // When found, check the rest of the hierarchy up to the class for runnability

done: b7ff142290026c6ee42e0713a8ca8dba1e54a7cd

> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 233:
> 
>> 231:     @Override
>> 232:     public boolean shouldReplace(@NotNull ConfigurationFromContext self, @NotNull ConfigurationFromContext other) {
>> 233:         final RunConfiguration otherCnf = other.getConfiguration();
> 
> Suggestion:
> 
>         RunConfiguration otherCnf = other.getConfiguration();

finals have been already removed in the last commit (a1350eb9ed33e626ffeab2518f656b226e5a1b96)

> plugins/idea/src/main/java/com/oracle/plugin/jtreg/util/JTRegUtils.java line 94:
> 
>> 92:     public static final Predicate<PsiElement> IS_DIR_ELEMENT = PsiDirectory.class::isInstance;
>> 93:     public static final Predicate<PsiElement> IS_FILE_ELEMENT = PsiFile.class::isInstance;
>> 94:     public static final Predicate<PsiElement> IS_FILE_OR_DIR_ELEMENT = IS_FILE_ELEMENT.or(IS_DIR_ELEMENT);
> 
> Why are these all predicates? I'd much prefer a set of static methods. These predicates make the logic harder to follow.

ok, no problem, I will replace them with methods.

> plugins/idea/src/main/java/com/oracle/plugin/jtreg/util/JTRegUtils.java line 355:
> 
>> 353:     public static boolean isRunnableByJTReg(@NotNull PsiElement element) {
>> 354:         final PsiFile runFile;
>> 355:         final PsiDirectory runDir;
> 
> Suggestion:
> 
>         PsiFile runFile;
>         PsiDirectory runDir;

finals have been already removed in the last commit (a1350eb9ed33e626ffeab2518f656b226e5a1b96)

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987218141
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987189818
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987190040
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987212635
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987189232
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987199807
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987188779

From duke at openjdk.org  Mon Mar 10 12:59:53 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 12:59:53 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <tCQcyT_YP1CUbTUCF_Ob_bbSlmh0cI17EWo6NtJ4d8A=.2f3e37fd-1493-4eb1-a5bc-0ef5e58e26ce@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <tCQcyT_YP1CUbTUCF_Ob_bbSlmh0cI17EWo6NtJ4d8A=.2f3e37fd-1493-4eb1-a5bc-0ef5e58e26ce@github.com>
Message-ID: <dTzejOWmBIWDW_i2mAInxQ_8lFiedjtIdoec7GNfvWw=.ecc0c2db-4adf-4a21-bcac-fef0816cf5bf@github.com>

On Mon, 10 Mar 2025 12:47:14 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegClassConfigurationProducer.java line 125:
>> 
>>> 123:             }
>>> 124:         }
>>> 125:     }
>> 
>>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> I think this issue is addressed in this code here.
>> 
>> What are the steps to reproduce this issue? When I try to create a run configuration through the context menu on the editor tab, I seem to get a JTreg configuration every time. Or I get the option to choose one or the other: 
>> ![image](https://github.com/user-attachments/assets/2a1abcf5-4e7d-45f8-a82e-9ea9d392a16a)
>
> ![test/jdk/java/foreign/TestSegmentBulkOperationsContentHash.java](https://github.com/user-attachments/assets/4db38b2a-9643-42df-a28b-01093f065424)

IntelliJ IDEA 2024.3.4.1 (Community Edition)
Build #IC-243.25659.59, built on March 5, 2025
Windows 10

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987221257

From jvernee at openjdk.org  Mon Mar 10 12:59:54 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Mar 2025 12:59:54 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
Message-ID: <yn-YLR98pZh6iLqagpvIkPMBH_RyJ4DaTvUE-gIohyo=.d25dc74b-5d8f-4d91-b07f-7c454ce0cee0@github.com>

On Mon, 10 Mar 2025 12:16:46 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## JTRegClassConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> 
>> ## JTRegConfigurationProducer.java
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
>> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
>> - Add a JUnit chec...
>
> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 128:
> 
>> 126: 
>> 127:             if (IS_THIRD_PARTY_TEST_ELEMENT.test(e)) {
>> 128:                 final PsiElement identifyingElement = ((PsiNameIdentifierOwner) e).getIdentifyingElement();
> 
> Suggestion:
> 
>                 PsiElement identifyingElement = ((PsiNameIdentifierOwner) e).getIdentifyingElement();

Also, I notice that this is code is trying to return a `PsiIdentifier` so that `getQuery` and `nameForElement` will keep working. It might be better to change those methods to work on `PsiMethod` and `PsiClass`, and then use the current `e` as return value directly.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987177177

From duke at openjdk.org  Mon Mar 10 13:14:23 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 13:14:23 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
Message-ID: <Bb_15d5zwqL_Vw-5HRM7R6g3XGwNu5M4jXIv-NITU6o=.4ae3b134-66ee-421c-a4dc-e3abfd0fb123@github.com>

On Mon, 10 Mar 2025 11:49:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## JTRegClassConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> 
>> ## JTRegConfigurationProducer.java
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
>> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
>> - Add a JUnit chec...
>
> plugins/idea/src/main/resources/META-INF/plugin.xml line 36:
> 
>> 34:     <depends>AntSupport</depends>
>> 35:     <depends>TestNG-J</depends>
>> 36:     <depends>JUnit</depends>
> 
> Is this required for `JUnitUtil` and `JUnitConfiguration`?

Yes, otherwise we get a runtime exception when context menu appears:

Caused by: java.lang.NoClassDefFoundError: com/intellij/execution/junit/JUnitConfiguration

`JUnitConfiguration` class is used in the method:
`com.oracle.plugin.jtreg.configuration.producers.JTRegConfigurationProducer#shouldReplace`:

![JTRegConfigurationProducer#shouldReplace](https://github.com/user-attachments/assets/dbf5e61e-f8fa-44df-9e7b-2bac0431a925)

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987258397

From jvernee at openjdk.org  Mon Mar 10 13:18:07 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Mar 2025 13:18:07 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <dTzejOWmBIWDW_i2mAInxQ_8lFiedjtIdoec7GNfvWw=.ecc0c2db-4adf-4a21-bcac-fef0816cf5bf@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <tCQcyT_YP1CUbTUCF_Ob_bbSlmh0cI17EWo6NtJ4d8A=.2f3e37fd-1493-4eb1-a5bc-0ef5e58e26ce@github.com>
 <dTzejOWmBIWDW_i2mAInxQ_8lFiedjtIdoec7GNfvWw=.ecc0c2db-4adf-4a21-bcac-fef0816cf5bf@github.com>
Message-ID: <d5nNV6Ekhty_lxTbla029EkorCqye6A8CHEY3a2Nee0=.39c42a96-de57-42c0-bdaa-0222a79f1d23@github.com>

On Mon, 10 Mar 2025 12:49:15 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> ![test/jdk/java/foreign/TestSegmentBulkOperationsContentHash.java](https://github.com/user-attachments/assets/4db38b2a-9643-42df-a28b-01093f065424)
>
> IntelliJ IDEA 2024.3.4.1 (Community Edition)
> Build #IC-243.25659.59, built on March 5, 2025
> Windows 10

Thanks. I'm able to reproduce the issue for JUnit tests when I comment out the call to `preventRunPriorityLoss`

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987263250

From duke at openjdk.org  Mon Mar 10 13:18:07 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 13:18:07 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <d5nNV6Ekhty_lxTbla029EkorCqye6A8CHEY3a2Nee0=.39c42a96-de57-42c0-bdaa-0222a79f1d23@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <tCQcyT_YP1CUbTUCF_Ob_bbSlmh0cI17EWo6NtJ4d8A=.2f3e37fd-1493-4eb1-a5bc-0ef5e58e26ce@github.com>
 <dTzejOWmBIWDW_i2mAInxQ_8lFiedjtIdoec7GNfvWw=.ecc0c2db-4adf-4a21-bcac-fef0816cf5bf@github.com>
 <d5nNV6Ekhty_lxTbla029EkorCqye6A8CHEY3a2Nee0=.39c42a96-de57-42c0-bdaa-0222a79f1d23@github.com>
Message-ID: <GNufCx7ivKrqxWOP_QpkzV1n3oEiuqh3I_vEuShFlSg=.feb81361-b743-496a-a4b9-e5cd84b48283@github.com>

On Mon, 10 Mar 2025 13:14:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> IntelliJ IDEA 2024.3.4.1 (Community Edition)
>> Build #IC-243.25659.59, built on March 5, 2025
>> Windows 10
>
> Thanks. I'm able to reproduce the issue for JUnit tests when I comment out the call to `preventRunPriorityLoss`

The same on a sanboxed IDEA:
IntelliJ IDEA 2024.2.0.2 (Community Edition)
Build #IC-242.20224.419, built on August 19, 2024

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987264722

From duke at openjdk.org  Mon Mar 10 13:27:15 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 13:27:15 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
Message-ID: <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>

On Mon, 10 Mar 2025 11:58:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## JTRegClassConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> 
>> ## JTRegConfigurationProducer.java
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
>> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
>> - Add a JUnit chec...
>
> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegClassConfigurationProducer.java line 73:
> 
>> 71:         if (element instanceof PsiDirectory runDir) {
>> 72:             configuration.setPackage(runDir.getVirtualFile().getPath());
>> 73:         } else {
> 
> If this producer can now handle directories too, do we still need `JTRegDirectoryConfigurationProducer`?
> 
> Also, for a directory this would end up calling `nameForElement` -> `element.getContainingFile().getName()`, where `getContainingFile` seemingly returns `null`, so I think that would fail.

`PsiDirectory#getVirtualFile` should not return `null` due to its annotated with `@NotNull`:

![PsiDirectory#getVirtualFile](https://github.com/user-attachments/assets/1d222ffe-5a3c-49cc-a70c-5e6a8daef9ac)

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987276848

From duke at openjdk.org  Mon Mar 10 13:27:15 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 13:27:15 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>
Message-ID: <QTN9PTB-IQUM8z14TG503oKhu8FsP7Na3Yx-o9apwc8=.7d92afc2-5f37-43b2-b458-1ecb4aeb6643@github.com>

On Mon, 10 Mar 2025 13:23:11 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegClassConfigurationProducer.java line 73:
>> 
>>> 71:         if (element instanceof PsiDirectory runDir) {
>>> 72:             configuration.setPackage(runDir.getVirtualFile().getPath());
>>> 73:         } else {
>> 
>> If this producer can now handle directories too, do we still need `JTRegDirectoryConfigurationProducer`?
>> 
>> Also, for a directory this would end up calling `nameForElement` -> `element.getContainingFile().getName()`, where `getContainingFile` seemingly returns `null`, so I think that would fail.
>
> `PsiDirectory#getVirtualFile` should not return `null` due to its annotated with `@NotNull`:
> 
> ![PsiDirectory#getVirtualFile](https://github.com/user-attachments/assets/1d222ffe-5a3c-49cc-a70c-5e6a8daef9ac)

On the other hand, a file element could produce null for `getVirtualFile()`:

![image](https://github.com/user-attachments/assets/15dcfd4b-7b87-4387-a0e8-440d65fff0e7)

ok, I will add check there

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987280068

From duke at openjdk.org  Mon Mar 10 13:33:26 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 13:33:26 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v2]
In-Reply-To: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
Message-ID: <62wxHUjqolyrPoGVXKUEKkqVqb8BwZV1RlzBKdX7_wM=.d10e1757-8799-4e2d-a4f6-74b463a016b5@github.com>

> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
> 
> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
> 
> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
> 
> - Editor tab
> - File in the project tree
> - Directory in the project tree
> - Any location within a file
> 
> The current changes automatically determine what needs to be executed:
> 
> - Directory
> - File
> - Method
> 
> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> # Summary
> 
> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
> - Improve the logic for comparing existing run configurations with newly generated ones.  
> - Add JUnit plugin in the dependencies.
> 
> # Detailed changes
> 
> ## Add JUnit plugin into dependencies
> - build.gradle
> - plugin.xml
> 
> ## JTRegClassConfigurationProducer.java
> - Refactor `setupConfigurationFromContext`:
>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>   - Allow this method to create configurations for directories as well.  
>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
> - Implement `preventRunPriorityLoss`.
> - Add Javadoc for `nameForElement`.
> 
> ## JTRegConfigurationProducer.java
> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
> - Add a JUnit check to the `shouldReplace` method.
> 
> ## JTRegUtils.java
> - Add a predicate to compare two strings ...

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

  JTRegClassConfigurationProducer: add `null` check for `setRunClass` case

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/252/files
  - new: https://git.openjdk.org/jtreg/pull/252/files/b7ff1422..3a3f1019

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

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

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

From duke at openjdk.org  Mon Mar 10 13:36:16 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 13:36:16 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v2]
In-Reply-To: <QTN9PTB-IQUM8z14TG503oKhu8FsP7Na3Yx-o9apwc8=.7d92afc2-5f37-43b2-b458-1ecb4aeb6643@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>
 <QTN9PTB-IQUM8z14TG503oKhu8FsP7Na3Yx-o9apwc8=.7d92afc2-5f37-43b2-b458-1ecb4aeb6643@github.com>
Message-ID: <KtrkgScj15Qv4v2v3DdCItz5DiXriRe3kU3onNdKz6o=.2cef9f32-4661-4bbc-9cde-0fdaedfdb921@github.com>

On Mon, 10 Mar 2025 13:25:08 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> `PsiDirectory#getVirtualFile` should not return `null` due to its annotated with `@NotNull`:
>> 
>> ![PsiDirectory#getVirtualFile](https://github.com/user-attachments/assets/1d222ffe-5a3c-49cc-a70c-5e6a8daef9ac)
>
> On the other hand, a file element could produce null for `getVirtualFile()`:
> 
> ![image](https://github.com/user-attachments/assets/15dcfd4b-7b87-4387-a0e8-440d65fff0e7)
> 
> ok, I will add check there

Added `null` check for the file-case: 3a3f10197c0670da4489d13b66cbabca10873b77

I will check if `JTRegDirectoryConfigurationProducer` is needed.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987297222

From duke at openjdk.org  Mon Mar 10 14:11:57 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 14:11:57 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v3]
In-Reply-To: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
Message-ID: <XrLYJupl6xJ9pPUVz-5jX_-vwo2ELQzJ8b7i8UDtQK8=.c84df541-979f-44c9-a802-0ef9f945dd9c@github.com>

> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
> 
> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
> 
> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
> 
> - Editor tab
> - File in the project tree
> - Directory in the project tree
> - Any location within a file
> 
> The current changes automatically determine what needs to be executed:
> 
> - Directory
> - File
> - Method
> 
> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> # Summary
> 
> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
> - Improve the logic for comparing existing run configurations with newly generated ones.  
> - Add JUnit plugin in the dependencies.
> 
> # Detailed changes
> 
> ## Add JUnit plugin into dependencies
> - build.gradle
> - plugin.xml
> 
> ## JTRegClassConfigurationProducer.java
> - Refactor `setupConfigurationFromContext`:
>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>   - Allow this method to create configurations for directories as well.  
>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
> - Implement `preventRunPriorityLoss`.
> - Add Javadoc for `nameForElement`.
> 
> ## JTRegConfigurationProducer.java
> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
> - Add a JUnit check to the `shouldReplace` method.
> 
> ## JTRegUtils.java
> - Add a predicate to compare two strings ...

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

  replace `JTRegUtils` predicates with static methods

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/252/files
  - new: https://git.openjdk.org/jtreg/pull/252/files/3a3f1019..8f97b8d0

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

  Stats: 35 lines in 2 files changed: 3 ins; 16 del; 16 mod
  Patch: https://git.openjdk.org/jtreg/pull/252.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/252/head:pull/252

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

From duke at openjdk.org  Mon Mar 10 14:11:59 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 14:11:59 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v3]
In-Reply-To: <tCQcyT_YP1CUbTUCF_Ob_bbSlmh0cI17EWo6NtJ4d8A=.2f3e37fd-1493-4eb1-a5bc-0ef5e58e26ce@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <tCQcyT_YP1CUbTUCF_Ob_bbSlmh0cI17EWo6NtJ4d8A=.2f3e37fd-1493-4eb1-a5bc-0ef5e58e26ce@github.com>
Message-ID: <6WKKpVt1e2K2nFMuITQr8OILsJJdhSZUMtgER8JaAfo=.1760cfe5-2198-449c-a322-61c38bdb5883@github.com>

On Mon, 10 Mar 2025 12:34:54 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> plugins/idea/src/main/java/com/oracle/plugin/jtreg/util/JTRegUtils.java line 94:
>> 
>>> 92:     public static final Predicate<PsiElement> IS_DIR_ELEMENT = PsiDirectory.class::isInstance;
>>> 93:     public static final Predicate<PsiElement> IS_FILE_ELEMENT = PsiFile.class::isInstance;
>>> 94:     public static final Predicate<PsiElement> IS_FILE_OR_DIR_ELEMENT = IS_FILE_ELEMENT.or(IS_DIR_ELEMENT);
>> 
>> Why are these all predicates? I'd much prefer a set of static methods. These predicates make the logic harder to follow.
>
> ok, no problem, I will replace them with methods.

done: 8f97b8d0f2fa0e08e9b705df8e30b6b72c4fe6cc

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987363546

From jvernee at openjdk.org  Mon Mar 10 14:24:26 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Mar 2025 14:24:26 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v3]
In-Reply-To: <KtrkgScj15Qv4v2v3DdCItz5DiXriRe3kU3onNdKz6o=.2cef9f32-4661-4bbc-9cde-0fdaedfdb921@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>
 <QTN9PTB-IQUM8z14TG503oKhu8FsP7Na3Yx-o9apwc8=.7d92afc2-5f37-43b2-b458-1ecb4aeb6643@github.com>
 <KtrkgScj15Qv4v2v3DdCItz5DiXriRe3kU3onNdKz6o=.2cef9f32-4661-4bbc-9cde-0fdaedfdb921@github.com>
Message-ID: <Iy_AMrbMSr-pbvJaIyXIVuMWUQbeDTxmbM8nHkNUFCg=.4fc316c2-c1af-49e3-b027-176245a96cab@github.com>

On Mon, 10 Mar 2025 13:33:42 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> On the other hand, a file element could produce null for `getVirtualFile()`:
>> 
>> ![image](https://github.com/user-attachments/assets/15dcfd4b-7b87-4387-a0e8-440d65fff0e7)
>> 
>> ok, I will add check there
>
> Added `null` check for the file-case: 3a3f10197c0670da4489d13b66cbabca10873b77
> 
> I will check if `JTRegDirectoryConfigurationProducer` is needed.

I'm not talking about `getVirtualFile`, I'm talking about the call to `getContainingFile`, inside `nameForElement`. If `element` is a `PsiDirectory`, then `getContainingFile` will return `null` (looking at the impl in `PsiDirectoryImpl`): 
![image](https://github.com/user-attachments/assets/1199772b-c6c0-429e-9db9-5872c048c921)

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987385411

From duke at openjdk.org  Mon Mar 10 14:24:26 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 14:24:26 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v3]
In-Reply-To: <Iy_AMrbMSr-pbvJaIyXIVuMWUQbeDTxmbM8nHkNUFCg=.4fc316c2-c1af-49e3-b027-176245a96cab@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>
 <QTN9PTB-IQUM8z14TG503oKhu8FsP7Na3Yx-o9apwc8=.7d92afc2-5f37-43b2-b458-1ecb4aeb6643@github.com>
 <KtrkgScj15Qv4v2v3DdCItz5DiXriRe3kU3onNdKz6o=.2cef9f32-4661-4bbc-9cde-0fdaedfdb921@github.com>
 <Iy_AMrbMSr-pbvJaIyXIVuMWUQbeDTxmbM8nHkNUFCg=.4fc316c2-c1af-49e3-b027-176245a96cab@github.com>
Message-ID: <dEFABsg61UzF2qcMVKE_fW0qGfqCiedRPy9wwfwzQQ0=.c1eb410b-2eb3-454c-ab6a-5ee0c99e316b@github.com>

On Mon, 10 Mar 2025 14:19:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Added `null` check for the file-case: 3a3f10197c0670da4489d13b66cbabca10873b77
>> 
>> I will check if `JTRegDirectoryConfigurationProducer` is needed.
>
> I'm not talking about `getVirtualFile`, I'm talking about the call to `getContainingFile`, inside `nameForElement`. If `element` is a `PsiDirectory`, then `getContainingFile` will return `null` (looking at the impl in `PsiDirectoryImpl`): 
> ![image](https://github.com/user-attachments/assets/1199772b-c6c0-429e-9db9-5872c048c921)

fixed as well

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987390044

From cstein at openjdk.org  Mon Mar 10 14:26:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 10 Mar 2025 14:26:19 GMT
Subject: RFR: 7903963: Fix "Run Configuration" Window Freeze Issue [v2]
In-Reply-To: <ZVZi0YaqvEqEBlifsII54c-3fT-ZI9EbrEVq2QVseQo=.60378641-0028-4d4c-ba5a-49180606120c@github.com>
References: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
 <ZVZi0YaqvEqEBlifsII54c-3fT-ZI9EbrEVq2QVseQo=.60378641-0028-4d4c-ba5a-49180606120c@github.com>
Message-ID: <ZnMgke5n1GsGeBHpgSoi7X7Ezom39_EGBiTGW2gUud8=.df8be0ba-98ad-481c-9694-ffdf4a5cff5b@github.com>

On Fri, 7 Mar 2025 17:30:19 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> # When the Problem Occurs
>> 
>> The JTReg "Run Configuration" window freezes when the user selects a JRE that is not present in the project's SDK list.
>> 
>> # Why the Problem Occurs
>> 
>> There is a method `applyEditorTo` in the `JTRegConfigurable.java` class, which is called repeatedly while the "Run Configuration" window is open. Within this method, the method `jrePathEditor.getJrePathOrName()` is invoked. As a result, when this method is called for a JRE path not listed in IDEA, it attempts to determine the Java version. If the user has selected a raw JDK image, a Java process is launched, and the version is obtained from the process output (see [org.jetbrains.jps.model.java.impl.JdkVersionDetectorImpl#detectJdkVersionInfo](https://github.com/JetBrains/intellij-community/blob/baba77ecf93f44a2ccb34e5b206e03c60817d511/jps/model-impl/src/org/jetbrains/jps/model/java/impl/JdkVersionDetectorImpl.java#L40)). 
>> 
>> This call is too resource-intensive to be executed on the UI thread, causing the window to freeze.
>> 
>> # Steps to reproduce
>> 
>> 1. Open a JDK project.  
>> 2. Open the "Project Structure" window.  
>> 3. Navigate to "Platform Settings ? SDKs".
>> 4. Remove the JDK that is used as the JRE for tests, or create a copy of this JDK on your file system.  
>> 5. Create a new "JTReg Run Configuration".  
>> 6. In the "JRE" field, select a JDK path that is not present in the Project SDK list (either the removed JDK or the copied one).  
>> 
>> ## Actual result
>> - The window starts freezing, even after saving and reopening it.
>> 
>> # Implemented Changes
>> 
>> ## JTRegConfigurable.java
>> - Fix Javadoc for the class.
>> - Remove unused class field: `jtregDir`.
>> - Add Javadoc to the methods: `createUIComponents`, `applyEditorTo`, `resetEditorFrom`
>> - Fix window freeze caused by `jrePathEditor` in the method `applyEditorTo`.
>> - Add method `applyEditorJrePathTo` to optimize data retrieval from `jrePathEditor`.
>> 
>> Since I implemented changes in this file, I also took the opportunity to clean up the code a bit.
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903963: Fix "Run Configuration" Window Freeze Issue
>   - remove `final` from local variables

Marked as reviewed by cstein (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/250#pullrequestreview-2671154930

From duke at openjdk.org  Mon Mar 10 14:34:14 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Mar 2025 14:34:14 GMT
Subject: RFR: 7903963: Fix "Run Configuration" Window Freeze Issue [v2]
In-Reply-To: <ZVZi0YaqvEqEBlifsII54c-3fT-ZI9EbrEVq2QVseQo=.60378641-0028-4d4c-ba5a-49180606120c@github.com>
References: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
 <ZVZi0YaqvEqEBlifsII54c-3fT-ZI9EbrEVq2QVseQo=.60378641-0028-4d4c-ba5a-49180606120c@github.com>
Message-ID: <7pLgt9Vo9R_FlHuAp4JIzHPVoUeO-uXESoEcnGY5ncI=.b3937e0e-3316-4d86-9879-fb09c59096f9@github.com>

On Fri, 7 Mar 2025 17:30:19 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> # When the Problem Occurs
>> 
>> The JTReg "Run Configuration" window freezes when the user selects a JRE that is not present in the project's SDK list.
>> 
>> # Why the Problem Occurs
>> 
>> There is a method `applyEditorTo` in the `JTRegConfigurable.java` class, which is called repeatedly while the "Run Configuration" window is open. Within this method, the method `jrePathEditor.getJrePathOrName()` is invoked. As a result, when this method is called for a JRE path not listed in IDEA, it attempts to determine the Java version. If the user has selected a raw JDK image, a Java process is launched, and the version is obtained from the process output (see [org.jetbrains.jps.model.java.impl.JdkVersionDetectorImpl#detectJdkVersionInfo](https://github.com/JetBrains/intellij-community/blob/baba77ecf93f44a2ccb34e5b206e03c60817d511/jps/model-impl/src/org/jetbrains/jps/model/java/impl/JdkVersionDetectorImpl.java#L40)). 
>> 
>> This call is too resource-intensive to be executed on the UI thread, causing the window to freeze.
>> 
>> # Steps to reproduce
>> 
>> 1. Open a JDK project.  
>> 2. Open the "Project Structure" window.  
>> 3. Navigate to "Platform Settings ? SDKs".
>> 4. Remove the JDK that is used as the JRE for tests, or create a copy of this JDK on your file system.  
>> 5. Create a new "JTReg Run Configuration".  
>> 6. In the "JRE" field, select a JDK path that is not present in the Project SDK list (either the removed JDK or the copied one).  
>> 
>> ## Actual result
>> - The window starts freezing, even after saving and reopening it.
>> 
>> # Implemented Changes
>> 
>> ## JTRegConfigurable.java
>> - Fix Javadoc for the class.
>> - Remove unused class field: `jtregDir`.
>> - Add Javadoc to the methods: `createUIComponents`, `applyEditorTo`, `resetEditorFrom`
>> - Fix window freeze caused by `jrePathEditor` in the method `applyEditorTo`.
>> - Add method `applyEditorJrePathTo` to optimize data retrieval from `jrePathEditor`.
>> 
>> Since I implemented changes in this file, I also took the opportunity to clean up the code a bit.
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7903963: Fix "Run Configuration" Window Freeze Issue
>   - remove `final` from local variables

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

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

PR Comment: https://git.openjdk.org/jtreg/pull/250#issuecomment-2710803867

From duke at openjdk.org  Mon Mar 10 14:40:14 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 14:40:14 GMT
Subject: Integrated: 7903963: Fix "Run Configuration" Window Freeze Issue
In-Reply-To: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
References: <buR4A0VWmDXBpUO67LGBXk94_mDk8BYHceFQcNrFs6Q=.50645911-a7e0-4f0a-96d4-5cc871f7cf6d@github.com>
Message-ID: <wnVdq0OsHQsjuphv3DHNd3fp4nrLx20AV2zSjGnmVj8=.62d1005b-4565-4a4d-b9ca-20298ff9ec3e@github.com>

On Wed, 5 Mar 2025 16:15:46 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> # When the Problem Occurs
> 
> The JTReg "Run Configuration" window freezes when the user selects a JRE that is not present in the project's SDK list.
> 
> # Why the Problem Occurs
> 
> There is a method `applyEditorTo` in the `JTRegConfigurable.java` class, which is called repeatedly while the "Run Configuration" window is open. Within this method, the method `jrePathEditor.getJrePathOrName()` is invoked. As a result, when this method is called for a JRE path not listed in IDEA, it attempts to determine the Java version. If the user has selected a raw JDK image, a Java process is launched, and the version is obtained from the process output (see [org.jetbrains.jps.model.java.impl.JdkVersionDetectorImpl#detectJdkVersionInfo](https://github.com/JetBrains/intellij-community/blob/baba77ecf93f44a2ccb34e5b206e03c60817d511/jps/model-impl/src/org/jetbrains/jps/model/java/impl/JdkVersionDetectorImpl.java#L40)). 
> 
> This call is too resource-intensive to be executed on the UI thread, causing the window to freeze.
> 
> # Steps to reproduce
> 
> 1. Open a JDK project.  
> 2. Open the "Project Structure" window.  
> 3. Navigate to "Platform Settings ? SDKs".
> 4. Remove the JDK that is used as the JRE for tests, or create a copy of this JDK on your file system.  
> 5. Create a new "JTReg Run Configuration".  
> 6. In the "JRE" field, select a JDK path that is not present in the Project SDK list (either the removed JDK or the copied one).  
> 
> ## Actual result
> - The window starts freezing, even after saving and reopening it.
> 
> # Implemented Changes
> 
> ## JTRegConfigurable.java
> - Fix Javadoc for the class.
> - Remove unused class field: `jtregDir`.
> - Add Javadoc to the methods: `createUIComponents`, `applyEditorTo`, `resetEditorFrom`
> - Fix window freeze caused by `jrePathEditor` in the method `applyEditorTo`.
> - Add method `applyEditorJrePathTo` to optimize data retrieval from `jrePathEditor`.
> 
> Since I implemented changes in this file, I also took the opportunity to clean up the code a bit.

This pull request has now been integrated.

Changeset: 1d63247e
Author:    Oleksii Sylichenko <a.silichenko at gmail.com>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/1d63247e6c76c8a1010035a310f11cf11ec8aae4
Stats:     78 lines in 1 file changed: 71 ins; 3 del; 4 mod

7903963: Fix "Run Configuration" Window Freeze Issue

Reviewed-by: jvernee, cstein

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

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

From duke at openjdk.org  Mon Mar 10 15:10:23 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 15:10:23 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v4]
In-Reply-To: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
Message-ID: <Fb9YJCNUy1Rndr3_Rwk4FYbBiejYDgr_3l8rfbuKMP0=.44bdcf3c-c4a3-4df4-b834-40f80435c4d1@github.com>

> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
> 
> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
> 
> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
> 
> - Editor tab
> - File in the project tree
> - Directory in the project tree
> - Any location within a file
> 
> The current changes automatically determine what needs to be executed:
> 
> - Directory
> - File
> - Method
> 
> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> # Summary
> 
> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
> - Improve the logic for comparing existing run configurations with newly generated ones.  
> - Add JUnit plugin in the dependencies.
> 
> # Detailed changes
> 
> ## Add JUnit plugin into dependencies
> - build.gradle
> - plugin.xml
> 
> ## JTRegClassConfigurationProducer.java
> - Refactor `setupConfigurationFromContext`:
>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>   - Allow this method to create configurations for directories as well.  
>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
> - Implement `preventRunPriorityLoss`.
> - Add Javadoc for `nameForElement`.
> 
> ## JTRegConfigurationProducer.java
> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
> - Add a JUnit check to the `shouldReplace` method.
> 
> ## JTRegUtils.java
> - Add a predicate to compare two strings ...

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

  Skip the class run config creation if the run file cannot be determined

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/252/files
  - new: https://git.openjdk.org/jtreg/pull/252/files/8f97b8d0..42b93ee8

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

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

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

From duke at openjdk.org  Mon Mar 10 15:56:22 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 15:56:22 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v4]
In-Reply-To: <Fb9YJCNUy1Rndr3_Rwk4FYbBiejYDgr_3l8rfbuKMP0=.44bdcf3c-c4a3-4df4-b834-40f80435c4d1@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <Fb9YJCNUy1Rndr3_Rwk4FYbBiejYDgr_3l8rfbuKMP0=.44bdcf3c-c4a3-4df4-b834-40f80435c4d1@github.com>
Message-ID: <KxH-nTWNavNB7Xp3WIFmpD-AfVtKa6k7LC9lPG4zeac=.738b773a-3eb0-4971-8a27-6ed014ade0cf@github.com>

On Mon, 10 Mar 2025 15:10:23 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## JTRegClassConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> 
>> ## JTRegConfigurationProducer.java
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
>> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
>> - Add a JUnit chec...
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skip the class run config creation if the run file cannot be determined

I'm going to remove a pair of code lines in the `JTRegClassConfigurationProducer#setupConfigurationFromContext`:


final Module originalModule = configuration.getConfigurationModule().getModule();
....
configuration.restoreOriginalModule(originalModule);


This code is only necessary when we change the module during the config creation, as it happens in `com.intellij.execution.junit.JUnitConfiguration#setupConfigurationFromContext`:

`setupConfigurationFromContext` -> `beClassConfiguration` -> `setMainClass` -> `setModule`


this.setModule(this.myData.setMainClass(testClass));


For the current JTReg plugin implementation, only simple field setters are called, and the module is not changed; therefore, this code is redundant.

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

PR Comment: https://git.openjdk.org/jtreg/pull/252#issuecomment-2711060799

From duke at openjdk.org  Mon Mar 10 16:50:09 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 10 Mar 2025 16:50:09 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v4]
In-Reply-To: <Iy_AMrbMSr-pbvJaIyXIVuMWUQbeDTxmbM8nHkNUFCg=.4fc316c2-c1af-49e3-b027-176245a96cab@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>
 <QTN9PTB-IQUM8z14TG503oKhu8FsP7Na3Yx-o9apwc8=.7d92afc2-5f37-43b2-b458-1ecb4aeb6643@github.com>
 <KtrkgScj15Qv4v2v3DdCItz5DiXriRe3kU3onNdKz6o=.2cef9f32-4661-4bbc-9cde-0fdaedfdb921@github.com>
 <Iy_AMrbMSr-pbvJaIyXIVuMWUQbeDTxmbM8nHkNUFCg=.4fc316c2-c1af-49e3-b027-176245a96cab@github.com>
Message-ID: <AdTqMijYCxPLs7DIFsFmjLpE3gl5A4jSdWsTRX-cH_w=.62d4de35-60b1-4f42-ae8b-7f7c7c254060@github.com>

On Mon, 10 Mar 2025 14:19:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Added `null` check for the file-case: 3a3f10197c0670da4489d13b66cbabca10873b77
>> 
>> I will check if `JTRegDirectoryConfigurationProducer` is needed.
>
> I'm not talking about `getVirtualFile`, I'm talking about the call to `getContainingFile`, inside `nameForElement`. If `element` is a `PsiDirectory`, then `getContainingFile` will return `null` (looking at the impl in `PsiDirectoryImpl`): 
> ![image](https://github.com/user-attachments/assets/1199772b-c6c0-429e-9db9-5872c048c921)

Ok, so the `JTRegDirectoryConfigurationProducer` class is not needed because directory processing will be handled by the 'class producer', and I will take care of additional `null` checks.

Therefore, we don't need `JTRegClassConfigurationProducer` as the only child of `JTRegConfigurationProducer`, so I propose moving all its code to the parent class and removing it as well.

Would that be okay?

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987670957

From cstein at openjdk.org  Mon Mar 10 17:43:10 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 10 Mar 2025 17:43:10 GMT
Subject: RFR: 7903961: Make default timeout configurable
In-Reply-To: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
References: <Fyl0DuY2R7BEfkssp5UacfhtlvnnnBBQA_iqkwgD0Gw=.b85198b0-c4fa-4d6b-8401-37a0c0430212@github.com>
Message-ID: <SVADqduaxKhieZoKR2rlXMM6mp7sgRUAIWes8ZVUPC8=.d8493cb3-4ec2-4b02-9c20-420fdeec5a72@github.com>

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

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

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

> 1129:     Map<String, String> getTestProperties()  {
> 1130:         // initialize the properties with standard properties common to all tests
> 1131:         Map<String, String> p = new TreeMap<>(params.getBasicTestProperties());

This change sorts all basic test properties by their name; keeping the insertion order was never a promise.

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

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

From jvernee at openjdk.org  Mon Mar 10 18:33:11 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Mar 2025 18:33:11 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v4]
In-Reply-To: <AdTqMijYCxPLs7DIFsFmjLpE3gl5A4jSdWsTRX-cH_w=.62d4de35-60b1-4f42-ae8b-7f7c7c254060@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>
 <QTN9PTB-IQUM8z14TG503oKhu8FsP7Na3Yx-o9apwc8=.7d92afc2-5f37-43b2-b458-1ecb4aeb6643@github.com>
 <KtrkgScj15Qv4v2v3DdCItz5DiXriRe3kU3onNdKz6o=.2cef9f32-4661-4bbc-9cde-0fdaedfdb921@github.com>
 <Iy_AMrbMSr-pbvJaIyXIVuMWUQbeDTxmbM8nHkNUFCg=.4fc316c2-c1af-49e3-b027-176245a96cab@github.com>
 <AdTqMijYCxPLs7DIFsFmjLpE3gl5A4jSdWsTRX-cH_w=.62d4de35-60b1-4f42-ae8b-7f7c7c254060@github.com>
Message-ID: <lQSxDoQzH-6KZZ5PkBsh_r_xI9W4soNJD3T_s1cwhRM=.cc0030d3-f8a5-42ee-adae-ad95c6ae1802@github.com>

On Mon, 10 Mar 2025 16:47:09 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> I'm not talking about `getVirtualFile`, I'm talking about the call to `getContainingFile`, inside `nameForElement`. If `element` is a `PsiDirectory`, then `getContainingFile` will return `null` (looking at the impl in `PsiDirectoryImpl`): 
>> ![image](https://github.com/user-attachments/assets/1199772b-c6c0-429e-9db9-5872c048c921)
>
> Ok, so the `JTRegDirectoryConfigurationProducer` class is not needed because directory processing will be handled by the 'class producer', and I will take care of additional `null` checks.
> 
> Therefore, we don't need `JTRegClassConfigurationProducer` as the only child of `JTRegConfigurationProducer`, so I propose moving all its code to the parent class and removing it as well.
> 
> Would that be okay?

That sounds good

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1987820091

From cstein at openjdk.org  Tue Mar 11 08:05:06 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Mar 2025 08:05:06 GMT
Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash
 testing
In-Reply-To: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
Message-ID: <4L83ugDYlgs15DFBD1WQmPcW-JxLYF-Xebf0WfmXMkE=.6909092d-c822-4be5-a57f-c5def33b3bbb@github.com>

On Wed, 6 Nov 2024 01:45:22 GMT, andrlos <duke at openjdk.org> wrote:

> provides SPI for enabling external status transformations of failed tests
> 
> this is a continuation of efforts after https://github.com/openjdk/jtharness/pull/59 
> 
> Requires newest jtharness build (not even tagged yet) that includes above mentioned change to be compiled succesfully
> 
> The main idea is to provide a unified StatusTransformer interface, that can be externally implemented by users and added to a classpath in a separate jar to allow modifications of test execution status based on some elementary analysis. This can be easily used for crashtesting (filtering out only tests with jvm crashes).

The use-case doesn't carry the weight of introducing and maintaining a SPI for arbitrary and distant test result mangling in the inards of `jtreg`. The aforementioned JUnit `TestRule` is a good example for a non-distant (think: test-local) way to influnce the result of a test in an understandable way.

In the light of the discussion above, I won't approve this pull request.

Let's discuss other approaches to achieve the goals expressed in https://bugs.openjdk.org/browse/CODETOOLS-7903519

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

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

From duke at openjdk.org  Tue Mar 11 16:35:53 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 16:35:53 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v5]
In-Reply-To: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
Message-ID: <_4Jd_DLg2ANMFn7-wIooJmy8qhexvwlSqVvIoMGcDds=.0b290b53-a538-4a1d-955a-be9689b3ac6f@github.com>

> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
> 
> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
> 
> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
> 
> - Editor tab
> - File in the project tree
> - Directory in the project tree
> - Any location within a file
> 
> The current changes automatically determine what needs to be executed:
> 
> - Directory
> - File
> - Method
> 
> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> # Summary
> 
> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
> - Improve the logic for comparing existing run configurations with newly generated ones.  
> - Add JUnit plugin in the dependencies.
> 
> # Detailed changes
> 
> ## Add JUnit plugin into dependencies
> - build.gradle
> - plugin.xml
> 
> ## JTRegClassConfigurationProducer.java
> - Refactor `setupConfigurationFromContext`:
>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>   - Allow this method to create configurations for directories as well.  
>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
> - Implement `preventRunPriorityLoss`.
> - Add Javadoc for `nameForElement`.
> 
> ## JTRegConfigurationProducer.java
> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
> - Add a JUnit check to the `shouldReplace` method.
> 
> ## JTRegUtils.java
> - Add a predicate to compare two strings ...

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

 - 7903965: Fix Launching Tests from Context Menu
   
   - merge the code of the dir and file config producers into a parent config producer
   - prevent configuration creation when multiple files or directories are selected
   - delete class config producer
   - delete dir config producer
   
   Use PsiClass/PsiMethod instead of PsiIdentifier:
   - `findExactRunElement()`
   - `nameForElement()`
   - `getQuery`
 - add javadoc for `JTRegUtils.isThirdPartyTestElement`
 - remove `JTRegUtils.isEqualNullAsEmpty`
 - replace `JTRegUtils.isEqualNullAsEmpty` with `Comparing.strEqual`

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/252/files
  - new: https://git.openjdk.org/jtreg/pull/252/files/42b93ee8..fc97ec59

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

  Stats: 397 lines in 5 files changed: 119 ins; 248 del; 30 mod
  Patch: https://git.openjdk.org/jtreg/pull/252.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/252/head:pull/252

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

From duke at openjdk.org  Tue Mar 11 16:35:54 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 16:35:54 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v5]
In-Reply-To: <lQSxDoQzH-6KZZ5PkBsh_r_xI9W4soNJD3T_s1cwhRM=.cc0030d3-f8a5-42ee-adae-ad95c6ae1802@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <YCWgwgUVkfsndm9uUEpMPT5kbgZON1ozPZjdrJ2oq38=.464ae964-fb1d-43ad-a073-f2b2b5d861e2@github.com>
 <QTN9PTB-IQUM8z14TG503oKhu8FsP7Na3Yx-o9apwc8=.7d92afc2-5f37-43b2-b458-1ecb4aeb6643@github.com>
 <KtrkgScj15Qv4v2v3DdCItz5DiXriRe3kU3onNdKz6o=.2cef9f32-4661-4bbc-9cde-0fdaedfdb921@github.com>
 <Iy_AMrbMSr-pbvJaIyXIVuMWUQbeDTxmbM8nHkNUFCg=.4fc316c2-c1af-49e3-b027-176245a96cab@github.com>
 <AdTqMijYCxPLs7DIFsFmjLpE3gl5A4jSdWsTRX-cH_w=.62d4de35-60b1-4f42-ae8b-7f7c7c254060@github.com>
 <lQSxDoQzH-6KZZ5PkBsh_r_xI9W4soNJD3T_s1cwhRM=.cc0030d3-f8a5-42ee-adae-ad95c6ae1802@github.com>
Message-ID: <_if_p8fZ1ZphdaMnz4Hy6T2ABnoETt5wRa6ag-e3Utg=.fa13316a-bf0c-4522-af14-2531aa08efc9@github.com>

On Mon, 10 Mar 2025 18:30:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Ok, so the `JTRegDirectoryConfigurationProducer` class is not needed because directory processing will be handled by the 'class producer', and I will take care of additional `null` checks.
>> 
>> Therefore, we don't need `JTRegClassConfigurationProducer` as the only child of `JTRegConfigurationProducer`, so I propose moving all its code to the parent class and removing it as well.
>> 
>> Would that be okay?
>
> That sounds good

done: fc97ec59d91a1625577509ff342e8d4c1b96ade8

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1989698653

From duke at openjdk.org  Tue Mar 11 16:35:54 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 16:35:54 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
Message-ID: <Fy4gzNMJ51BuAuWpIC1mbJJUJx7f3yLYI1d3vLXclW8=.7489c0cf-5e1a-4ced-b243-44560b32baa3@github.com>

On Mon, 10 Mar 2025 12:45:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## JTRegClassConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> 
>> ## JTRegConfigurationProducer.java
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
>> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
>> - Add a JUnit chec...
>
> I've created https://bugs.openjdk.org/browse/CODETOOLS-7903965 for this PR

@JornVernee please reiew

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

PR Comment: https://git.openjdk.org/jtreg/pull/252#issuecomment-2715001321

From duke at openjdk.org  Tue Mar 11 16:35:56 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 16:35:56 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v5]
In-Reply-To: <yn-YLR98pZh6iLqagpvIkPMBH_RyJ4DaTvUE-gIohyo=.d25dc74b-5d8f-4d91-b07f-7c454ce0cee0@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <5FApqPPpD9MmCtHagG1QOfLBA3-oFig2ZZaLSqxCC4Y=.82c93976-8ed1-411b-ab19-156ce386c5a9@github.com>
 <yn-YLR98pZh6iLqagpvIkPMBH_RyJ4DaTvUE-gIohyo=.d25dc74b-5d8f-4d91-b07f-7c454ce0cee0@github.com>
Message-ID: <UNTG-boqIxpv7O7JVTmEKbd2drM5S0upPUWrkQynbe0=.76ea31e9-a8c5-4750-bcef-8a46961d51fe@github.com>

On Mon, 10 Mar 2025 12:21:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 128:
>> 
>>> 126: 
>>> 127:             if (IS_THIRD_PARTY_TEST_ELEMENT.test(e)) {
>>> 128:                 final PsiElement identifyingElement = ((PsiNameIdentifierOwner) e).getIdentifyingElement();
>> 
>> Suggestion:
>> 
>>                 PsiElement identifyingElement = ((PsiNameIdentifierOwner) e).getIdentifyingElement();
>
> Also, I notice that this is code is trying to return a `PsiIdentifier` so that `getQuery` and `nameForElement` will keep working. It might be better to change those methods to work on `PsiMethod` and `PsiClass`, and then use the current `e` as return value directly.

done: fc97ec59d91a1625577509ff342e8d4c1b96ade8

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1989699264

From duke at openjdk.org  Tue Mar 11 16:38:15 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 16:38:15 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v4]
In-Reply-To: <Fb9YJCNUy1Rndr3_Rwk4FYbBiejYDgr_3l8rfbuKMP0=.44bdcf3c-c4a3-4df4-b834-40f80435c4d1@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <Fb9YJCNUy1Rndr3_Rwk4FYbBiejYDgr_3l8rfbuKMP0=.44bdcf3c-c4a3-4df4-b834-40f80435c4d1@github.com>
Message-ID: <ySk8ti6m9nkQ35fLvFKE_FlrhCNXH9q5eWnkXArOgSU=.ee08eb2b-494c-4a93-af81-e4c5a2063ee8@github.com>

On Mon, 10 Mar 2025 15:10:23 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## JTRegClassConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> 
>> ## JTRegConfigurationProducer.java
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
>> - Implement `findExactRunElement` to locate the specific PSI element for execution among the current element?s parents.
>> - Add a JUnit chec...
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skip the class run config creation if the run file cannot be determined

Additionally, it is implemented to not create a run configuration if more than one file or directory is selected: fc97ec59d91a1625577509ff342e8d4c1b96ade8

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

PR Comment: https://git.openjdk.org/jtreg/pull/252#issuecomment-2715009595

From duke at openjdk.org  Tue Mar 11 17:11:29 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 17:11:29 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v6]
In-Reply-To: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
Message-ID: <Dyhva2k2AVSKi_MVym3Y07CqBo-YUfNoERurRtDBlvU=.b133a38a-f3a0-4236-a563-0dd6772902d3@github.com>

> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
> 
> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
> 
> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
> 
> - Editor tab
> - File in the project tree
> - Directory in the project tree
> - Any location within a file
> 
> The current changes automatically determine what needs to be executed:
> 
> - Directory
> - File
> - Method
> 
> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> # Summary
> 
> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
> - Improve the logic for comparing existing run configurations with newly generated ones.  
> - Add JUnit plugin in the dependencies.
> 
> # Detailed changes
> 
> ## Add JUnit plugin into dependencies
> - build.gradle
> - plugin.xml
> 
> ## Removed files
> Merge the code of the directory and file config producers into a parent config producer.
> - JTRegClassConfigurationProducer.java
> - JTRegDirectoryConfigurationProducer.java
> 
> ## JTRegConfigurationProducer.java
> - Refactor `setupConfigurationFromContext`:
>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>   - Allow this method to create configurations for directories as well.  
>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
> - Implement `preventRunPriorityLoss`.
> - Add Javadoc for `nameForElement`.
> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
> - Implement `findExactRunElement` to locate the specific PSI element for execution a...

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

  Revert: prevent configuration creation when multiple files or directories are selected

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/252/files
  - new: https://git.openjdk.org/jtreg/pull/252/files/fc97ec59..4025db9f

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

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

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

From duke at openjdk.org  Tue Mar 11 17:14:12 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 17:14:12 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v6]
In-Reply-To: <Dyhva2k2AVSKi_MVym3Y07CqBo-YUfNoERurRtDBlvU=.b133a38a-f3a0-4236-a563-0dd6772902d3@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <Dyhva2k2AVSKi_MVym3Y07CqBo-YUfNoERurRtDBlvU=.b133a38a-f3a0-4236-a563-0dd6772902d3@github.com>
Message-ID: <0NGJUqNgQbg08_DGKAE9kwEVANDvMS8XEJxwuaYFWqU=.b9812b14-87bf-47f5-b9cb-049fa5c03202@github.com>

On Tue, 11 Mar 2025 17:11:29 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## Removed files
>> Merge the code of the directory and file config producers into a parent config producer.
>> - JTRegClassConfigurationProducer.java
>> - JTRegDirectoryConfigurationProducer.java
>> 
>> ## JTRegConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`nu...
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert: prevent configuration creation when multiple files or directories are selected

I encountered a case with multiple file selections, but decided to keep the current behavior: the run config is created for the first selected item. In general, for TestNG/JUnit, special "*PatternConfigProducer" classes are used.

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

PR Comment: https://git.openjdk.org/jtreg/pull/252#issuecomment-2715115032

From jvernee at openjdk.org  Tue Mar 11 18:35:08 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Mar 2025 18:35:08 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v6]
In-Reply-To: <Dyhva2k2AVSKi_MVym3Y07CqBo-YUfNoERurRtDBlvU=.b133a38a-f3a0-4236-a563-0dd6772902d3@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <Dyhva2k2AVSKi_MVym3Y07CqBo-YUfNoERurRtDBlvU=.b133a38a-f3a0-4236-a563-0dd6772902d3@github.com>
Message-ID: <99aGAdgc4N6nXH_I9Gz9gJ3BO77SW8g7lKr2CgsHTPY=.49d487cd-dfe8-4982-ae37-b469bb63fee9@github.com>

On Tue, 11 Mar 2025 17:11:29 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## Removed files
>> Merge the code of the directory and file config producers into a parent config producer.
>> - JTRegClassConfigurationProducer.java
>> - JTRegDirectoryConfigurationProducer.java
>> 
>> ## JTRegConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`nu...
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert: prevent configuration creation when multiple files or directories are selected

Great work! Just some minor inline comments

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 112:

> 110:             element = findExactRunElement(element);
> 111: 
> 112:             configuration.setQuery(getQuery(element));

Suggestion:

            preventRunPriorityLoss(element, sourceElement);
            element = findExactRunElement(element);
            configuration.setQuery(getQuery(element));

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 127:

> 125:      * The class {@link com.intellij.execution.actions.PreferredProducerFind} sorts the applicable runners using
> 126:      * {@link com.intellij.execution.actions.ConfigurationFromContext#COMPARATOR},
> 127:      * removing more general ones and retaining more specific or equal configurations.

The last line in this paragraph is a bit vague. The key issue here is that the IDE prefers config A over config B, if the `sourceElement` of A is nested somewhere inside B. So, we essentially use a hack here, by choosing one of the classes nested in the file that we are trying to run, so that we don't get beaten in the sorting order.

Just wanted to mention this for posterity. Maybe this could be called out explicitly:

Suggestion:

     * The class {@link com.intellij.execution.actions.PreferredProducerFind} sorts the applicable runners using
     * {@link com.intellij.execution.actions.ConfigurationFromContext#COMPARATOR}. This comparator prefers
     * configuration A over configuration B, when the source element of A is nested in B.

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

PR Review: https://git.openjdk.org/jtreg/pull/252#pullrequestreview-2675550972
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1989829804
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1989900387

From duke at openjdk.org  Tue Mar 11 19:58:54 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 19:58:54 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v7]
In-Reply-To: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
Message-ID: <Uionkyw6EJepA0Hpb0XT-_FjrcBZ_RjcSnY3nCnsBro=.cefe4762-2a08-413f-b038-42ca43b15730@github.com>

> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
> 
> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
> 
> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
> 
> - Editor tab
> - File in the project tree
> - Directory in the project tree
> - Any location within a file
> 
> The current changes automatically determine what needs to be executed:
> 
> - Directory
> - File
> - Method
> 
> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> # Summary
> 
> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
> - Improve the logic for comparing existing run configurations with newly generated ones.  
> - Add JUnit plugin in the dependencies.
> 
> # Detailed changes
> 
> ## Add JUnit plugin into dependencies
> - build.gradle
> - plugin.xml
> 
> ## Removed files
> Merge the code of the directory and file config producers into a parent config producer.
> - JTRegClassConfigurationProducer.java
> - JTRegDirectoryConfigurationProducer.java
> 
> ## JTRegConfigurationProducer.java
> - Refactor `setupConfigurationFromContext`:
>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>   - Allow this method to create configurations for directories as well.  
>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
> - Implement `preventRunPriorityLoss`.
> - Add Javadoc for `nameForElement`.
> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
> - Implement `findExactRunElement` to locate the specific PSI element for execution a...

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

 - clarify javadoc about the config comparator
 - remove empty lines

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/252/files
  - new: https://git.openjdk.org/jtreg/pull/252/files/4025db9f..4893fdd5

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

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

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

From duke at openjdk.org  Tue Mar 11 19:58:57 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Tue, 11 Mar 2025 19:58:57 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v6]
In-Reply-To: <99aGAdgc4N6nXH_I9Gz9gJ3BO77SW8g7lKr2CgsHTPY=.49d487cd-dfe8-4982-ae37-b469bb63fee9@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <Dyhva2k2AVSKi_MVym3Y07CqBo-YUfNoERurRtDBlvU=.b133a38a-f3a0-4236-a563-0dd6772902d3@github.com>
 <99aGAdgc4N6nXH_I9Gz9gJ3BO77SW8g7lKr2CgsHTPY=.49d487cd-dfe8-4982-ae37-b469bb63fee9@github.com>
Message-ID: <4L9dL-0sKjsgSnFPEkkAjUWdD6chobqFFuU7WRSRr2U=.7b8d14e7-6d45-4099-a0fb-2a5b1046fa5f@github.com>

On Tue, 11 Mar 2025 17:39:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert: prevent configuration creation when multiple files or directories are selected
>
> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 112:
> 
>> 110:             element = findExactRunElement(element);
>> 111: 
>> 112:             configuration.setQuery(getQuery(element));
> 
> Suggestion:
> 
>             preventRunPriorityLoss(element, sourceElement);
>             element = findExactRunElement(element);
>             configuration.setQuery(getQuery(element));

done

> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 127:
> 
>> 125:      * The class {@link com.intellij.execution.actions.PreferredProducerFind} sorts the applicable runners using
>> 126:      * {@link com.intellij.execution.actions.ConfigurationFromContext#COMPARATOR},
>> 127:      * removing more general ones and retaining more specific or equal configurations.
> 
> The last line in this paragraph is a bit vague. The key issue here is that the IDE prefers config A over config B, if the `sourceElement` of A is nested somewhere inside B. So, we essentially use a hack here, by choosing one of the classes nested in the file that we are trying to run, so that we don't get beaten in the sorting order.
> 
> Just wanted to mention this for posterity. Maybe this could be called out explicitly:
> 
> Suggestion:
> 
>      * The class {@link com.intellij.execution.actions.PreferredProducerFind} sorts the applicable runners using
>      * {@link com.intellij.execution.actions.ConfigurationFromContext#COMPARATOR}. This comparator prefers
>      * configuration A over configuration B, when the source element of A is nested in B.

done

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1990036644
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1990036941

From jvernee at openjdk.org  Tue Mar 11 20:41:08 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Mar 2025 20:41:08 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v7]
In-Reply-To: <Uionkyw6EJepA0Hpb0XT-_FjrcBZ_RjcSnY3nCnsBro=.cefe4762-2a08-413f-b038-42ca43b15730@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <Uionkyw6EJepA0Hpb0XT-_FjrcBZ_RjcSnY3nCnsBro=.cefe4762-2a08-413f-b038-42ca43b15730@github.com>
Message-ID: <Eg5IePp2i3TOtvhY0zqTQXs1m0puer8x7xfJwCxmdjw=.6745aa55-f922-4708-942e-ed2b5f886b20@github.com>

On Tue, 11 Mar 2025 19:58:54 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## Removed files
>> Merge the code of the directory and file config producers into a parent config producer.
>> - JTRegClassConfigurationProducer.java
>> - JTRegDirectoryConfigurationProducer.java
>> 
>> ## JTRegConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`nu...
>
> Oleksii Sylichenko has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - clarify javadoc about the config comparator
>  - remove empty lines

Marked as reviewed by jvernee (Committer).

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

PR Review: https://git.openjdk.org/jtreg/pull/252#pullrequestreview-2676069259

From cstein at openjdk.org  Tue Mar 11 20:49:11 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Mar 2025 20:49:11 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v7]
In-Reply-To: <Uionkyw6EJepA0Hpb0XT-_FjrcBZ_RjcSnY3nCnsBro=.cefe4762-2a08-413f-b038-42ca43b15730@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <Uionkyw6EJepA0Hpb0XT-_FjrcBZ_RjcSnY3nCnsBro=.cefe4762-2a08-413f-b038-42ca43b15730@github.com>
Message-ID: <hiQ7KGX1-AWdwk2CEHaqLNhevKIZKoTaTiY6UFStBSs=.302742ac-8dac-46b0-a0fb-76623d5f3afd@github.com>

On Tue, 11 Mar 2025 19:58:54 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## Removed files
>> Merge the code of the directory and file config producers into a parent config producer.
>> - JTRegClassConfigurationProducer.java
>> - JTRegDirectoryConfigurationProducer.java
>> 
>> ## JTRegConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`nu...
>
> Oleksii Sylichenko has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - clarify javadoc about the config comparator
>  - remove empty lines

Marked as reviewed by cstein (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/252#pullrequestreview-2676083605

From duke at openjdk.org  Wed Mar 12 14:12:13 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Mar 2025 14:12:13 GMT
Subject: RFR: 7903965: Fix Launching Tests from Context Menu [v7]
In-Reply-To: <Uionkyw6EJepA0Hpb0XT-_FjrcBZ_RjcSnY3nCnsBro=.cefe4762-2a08-413f-b038-42ca43b15730@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
 <Uionkyw6EJepA0Hpb0XT-_FjrcBZ_RjcSnY3nCnsBro=.cefe4762-2a08-413f-b038-42ca43b15730@github.com>
Message-ID: <zJ6AWjay0gjks2b31MEkOWGepeJKOwrw-oH8hy4VbD8=.83893a98-485a-4d6a-bf2e-de746b8c4cee@github.com>

On Tue, 11 Mar 2025 19:58:54 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## Removed files
>> Merge the code of the directory and file config producers into a parent config producer.
>> - JTRegClassConfigurationProducer.java
>> - JTRegDirectoryConfigurationProducer.java
>> 
>> ## JTRegConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`nu...
>
> Oleksii Sylichenko has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - clarify javadoc about the config comparator
>  - remove empty lines

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

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

PR Comment: https://git.openjdk.org/jtreg/pull/252#issuecomment-2718011848

From duke at openjdk.org  Wed Mar 12 14:28:14 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Wed, 12 Mar 2025 14:28:14 GMT
Subject: Integrated: 7903965: Fix Launching Tests from Context Menu
In-Reply-To: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
References: <sPdPrfssseoWmtndDvaSeI0oqUf88RdkngqSRGFkDzk=.79a12f13-b942-41ad-8b6b-d964dde7e1f2@github.com>
Message-ID: <WeRH12DCNXFP5oom_OI2zxhFjAAGxWgbg0-pqc-NCW8=.8edba0d9-f17f-46d6-b055-dde2e0956adf@github.com>

On Wed, 5 Mar 2025 17:28:47 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
> 
> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
> 
> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
> 
> - Editor tab
> - File in the project tree
> - Directory in the project tree
> - Any location within a file
> 
> The current changes automatically determine what needs to be executed:
> 
> - Directory
> - File
> - Method
> 
> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
> 
> # Summary
> 
> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
> - Improve the logic for comparing existing run configurations with newly generated ones.  
> - Add JUnit plugin in the dependencies.
> 
> # Detailed changes
> 
> ## Add JUnit plugin into dependencies
> - build.gradle
> - plugin.xml
> 
> ## Removed files
> Merge the code of the directory and file config producers into a parent config producer.
> - JTRegClassConfigurationProducer.java
> - JTRegDirectoryConfigurationProducer.java
> 
> ## JTRegConfigurationProducer.java
> - Refactor `setupConfigurationFromContext`:
>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>   - Allow this method to create configurations for directories as well.  
>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
> - Implement `preventRunPriorityLoss`.
> - Add Javadoc for `nameForElement`.
> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
> - Compare string-typed configuration parameters using a "not-nullify" approach (`null == ""`).
> - Implement `findExactRunElement` to locate the specific PSI element for execution a...

This pull request has now been integrated.

Changeset: 9e3e2303
Author:    Oleksii Sylichenko <a.silichenko at gmail.com>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/9e3e2303f98cc329db2c7bc4d13df741010a4391
Stats:     423 lines in 6 files changed: 227 ins; 165 del; 31 mod

7903965: Fix Launching Tests from Context Menu

Reviewed-by: jvernee, cstein

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

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

From cstein at openjdk.org  Wed Mar 12 15:35:46 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 12 Mar 2025 15:35:46 GMT
Subject: RFR: 7903969: Update year in copyright message
Message-ID: <2VdbXMLZZpITM26Q3tdu9HVpjRI5SMgnIttMfb78ybY=.40859da0-eacf-45f9-ae74-a05183ba4895@github.com>

Please review this change updating the second year of the copyright to 2025.

This PR also removes the copyright from command-line printouts of `jtreg` and `jtdiff`, for example in `jtreg --help` calls.

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

Commit messages:
 - 7903969: Update year in copyright message

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

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

From cstein at openjdk.org  Wed Mar 12 15:41:38 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 12 Mar 2025 15:41:38 GMT
Subject: RFR: 7903969: Update year in copyright message [v2]
In-Reply-To: <2VdbXMLZZpITM26Q3tdu9HVpjRI5SMgnIttMfb78ybY=.40859da0-eacf-45f9-ae74-a05183ba4895@github.com>
References: <2VdbXMLZZpITM26Q3tdu9HVpjRI5SMgnIttMfb78ybY=.40859da0-eacf-45f9-ae74-a05183ba4895@github.com>
Message-ID: <sW6LGb68iLwbc-kd6E9wlPrg5pWz9q1MkgAwn_wFb_Y=.22184feb-59cd-4b7a-9e55-b234aa4379b3@github.com>

> Please review this change updating the second year of the copyright to 2025.
> 
> This PR also removes the copyright from command-line printouts of `jtreg` and `jtdiff`, for example in `jtreg --help` calls.

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

  Remove unused message

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/254/files
  - new: https://git.openjdk.org/jtreg/pull/254/files/e5027369..f13ff38b

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

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

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

From iris at openjdk.org  Wed Mar 12 16:28:14 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 12 Mar 2025 16:28:14 GMT
Subject: RFR: 7903969: Update year in copyright message [v2]
In-Reply-To: <sW6LGb68iLwbc-kd6E9wlPrg5pWz9q1MkgAwn_wFb_Y=.22184feb-59cd-4b7a-9e55-b234aa4379b3@github.com>
References: <2VdbXMLZZpITM26Q3tdu9HVpjRI5SMgnIttMfb78ybY=.40859da0-eacf-45f9-ae74-a05183ba4895@github.com>
 <sW6LGb68iLwbc-kd6E9wlPrg5pWz9q1MkgAwn_wFb_Y=.22184feb-59cd-4b7a-9e55-b234aa4379b3@github.com>
Message-ID: <b3xP7VtQfWQCU64y9qlKSgqfpxVmeL0lyXBPtmndSiU=.48d799e5-8354-40f0-a88c-21488ee2db48@github.com>

On Wed, 12 Mar 2025 15:41:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change updating the second year of the copyright to 2025.
>> 
>> This PR also removes the copyright from command-line printouts of `jtreg` and `jtdiff`, for example in `jtreg --help` calls.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused message

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/254#pullrequestreview-2679135805

From cstein at openjdk.org  Wed Mar 12 16:38:12 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 12 Mar 2025 16:38:12 GMT
Subject: Integrated: 7903969: Update year in copyright message
In-Reply-To: <2VdbXMLZZpITM26Q3tdu9HVpjRI5SMgnIttMfb78ybY=.40859da0-eacf-45f9-ae74-a05183ba4895@github.com>
References: <2VdbXMLZZpITM26Q3tdu9HVpjRI5SMgnIttMfb78ybY=.40859da0-eacf-45f9-ae74-a05183ba4895@github.com>
Message-ID: <IcqVAUjL1Ng2c5xzH5H2l2M6zWlT5KqRQgGfJCU68V0=.e9cc2ca4-31d3-45b7-be39-e3be0a3db851@github.com>

On Wed, 12 Mar 2025 15:31:15 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change updating the second year of the copyright to 2025.
> 
> This PR also removes the copyright from command-line printouts of `jtreg` and `jtdiff`, for example in `jtreg --help` calls.

This pull request has now been integrated.

Changeset: 6a611a34
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/6a611a34bb735df082547e261d4d121267f564ac
Stats:     12 lines in 4 files changed: 0 ins; 8 del; 4 mod

7903969: Update year in copyright message

Reviewed-by: iris

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

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

From iris at openjdk.org  Mon Mar 17 20:08:19 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 17 Mar 2025 20:08:19 GMT
Subject: RFR: 7903955: jtreg doesn't support .jasm in patch module [v4]
In-Reply-To: <zfuv1Cy8St1Sgo054bsv-1vRWNfoeIM35LZ9nuU9UyY=.ecece9e7-9505-44b6-9f9f-35eed9f2adb4@github.com>
References: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
 <zfuv1Cy8St1Sgo054bsv-1vRWNfoeIM35LZ9nuU9UyY=.ecece9e7-9505-44b6-9f9f-35eed9f2adb4@github.com>
Message-ID: <6eeNAsI7pbd6V4doei51GfTm9R9brWh5ncX8EX6-9f8=.8d9d3414-23f4-4e1c-9d81-e356b6fbe77e@github.com>

On Wed, 5 Mar 2025 13:35:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to support compilation of `.jasm` in patched modules.
>> 
>> Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update ModLibsTest.gmk

No concerns discovered after historical investigation.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/249#pullrequestreview-2691855961

From cstein at openjdk.org  Tue Mar 18 06:50:20 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 18 Mar 2025 06:50:20 GMT
Subject: Integrated: 7903955: jtreg doesn't support .jasm in patch module
In-Reply-To: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
References: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
Message-ID: <DYJPaUjiECI2VX3GawnXmr1bYLU4WN0iby9G4tJ9O00=.cbf5d70c-28db-40d4-9588-09ae89e5e5e6@github.com>

On Fri, 28 Feb 2025 10:20:24 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to support compilation of `.jasm` in patched modules.
> 
> Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.

This pull request has now been integrated.

Changeset: 79d3fee3
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/79d3fee395060a48e8ce95f80345033953ee65d2
Stats:     56 lines in 5 files changed: 34 ins; 17 del; 5 mod

7903955: jtreg doesn't support .jasm in patch module

Reviewed-by: jpai, iris

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

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

From duke at openjdk.org  Mon Mar 24 21:14:24 2025
From: duke at openjdk.org (andrlos)
Date: Mon, 24 Mar 2025 21:14:24 GMT
Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash
 testing
In-Reply-To: <4L83ugDYlgs15DFBD1WQmPcW-JxLYF-Xebf0WfmXMkE=.6909092d-c822-4be5-a57f-c5def33b3bbb@github.com>
References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
 <4L83ugDYlgs15DFBD1WQmPcW-JxLYF-Xebf0WfmXMkE=.6909092d-c822-4be5-a57f-c5def33b3bbb@github.com>
Message-ID: <m7_JOUWF242CtsSZ91cNWvF8E0XSeFdf6r8VzW_0joo=.f3a31b60-3016-4516-8cb8-4f796710965a@github.com>

On Tue, 11 Mar 2025 08:02:32 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> provides SPI for enabling external status transformations of failed tests
>> 
>> this is a continuation of efforts after https://github.com/openjdk/jtharness/pull/59 
>> 
>> Requires newest jtharness build (not even tagged yet) that includes above mentioned change to be compiled succesfully
>> 
>> The main idea is to provide a unified StatusTransformer interface, that can be externally implemented by users and added to a classpath in a separate jar to allow modifications of test execution status based on some elementary analysis. This can be easily used for crashtesting (filtering out only tests with jvm crashes).
>
> The use-case doesn't carry the weight of introducing and maintaining a SPI for arbitrary and distant test result mangling in the inards of `jtreg`. The aforementioned JUnit `TestRule` is a good example for a non-distant (think: test-local) way to influnce the result of a test in an understandable way.
> 
> In the light of the discussion above, I won't approve this pull request.
> 
> Let's discuss other approaches to achieve the goals expressed in https://bugs.openjdk.org/browse/CODETOOLS-7903519

Hi @sormuras do you have any ideas about possible approach? It seems that I either lost my openjdk login or I never had one to start with.. I will try and get it while you can start the discussion there. Thanks!

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

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

From lmesnik at openjdk.org  Tue Mar 25 17:52:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 17:52:11 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used to
 compile a library
Message-ID: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@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 the libraries like '/test/lib' might be precompiled during build without tests and be used as classpath during test execution.

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

Commit messages:
 - 7902847

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

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

From lmesnik at openjdk.org  Tue Mar 25 23:09:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 23:09:41 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v2]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <t_pK_Cb9GOn2FAuE5Se2DOJfk7YFyGZC5cZkNONUYjg=.8b3c704c-4b82-457f-9ded-3868e55cd47b@github.com>

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

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

  test updated

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/6079e8f2..d5aca4dc

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

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

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

From lmesnik at openjdk.org  Wed Mar 26 00:45:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Mar 2025 00:45:39 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v3]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <80klpcv184ZiGCa_ARxSz_Kora4CufZ5S9ezYyHCmkc=.1ebc19a2-5b4a-4770-b241-b2c77e3d15c5@github.com>

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

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

  tests fixed to expect lib classes along with test classes.

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/256/files
  - new: https://git.openjdk.org/jtreg/pull/256/files/d5aca4dc..07a65a2d

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

  Stats: 37 lines in 2 files changed: 18 ins; 8 del; 11 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 jpai at openjdk.org  Wed Mar 26 15:11:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Mar 2025 15:11:37 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v3]
In-Reply-To: <80klpcv184ZiGCa_ARxSz_Kora4CufZ5S9ezYyHCmkc=.1ebc19a2-5b4a-4770-b241-b2c77e3d15c5@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <80klpcv184ZiGCa_ARxSz_Kora4CufZ5S9ezYyHCmkc=.1ebc19a2-5b4a-4770-b241-b2c77e3d15c5@github.com>
Message-ID: <Tb8hvQqUelaU5Rz3Cz0Xe2kB4U2sKScMm0cCrE36aGg=.606cce6e-d82b-4b92-85f7-2a185754f02d@github.com>

On Wed, 26 Mar 2025 00:45:39 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:
> 
>   tests fixed to expect lib classes along with test classes.

Hello Leonid,

Not a code review, but a general review about the proposal.

> The only reliable fix would be don't use shared class directory at all and compile all libraries for each test.

By all libraries, do you mean all classes that reside under the directory tree of each of the `@library` that been declared on a specific test definition?

> Although it looks like huge performance overhead, the impact is low. 

The before/after numbers that you posted for the JDK repo look reasonable. JDK isn't the sole user of `jtreg`, but yes I think it's the largest user, so we might have to consider if this change needs to be configurable in some way to allow select projects (like the JDK) to opt-in to this new behaviour.

> The libraries are not often compiled using build tag.

I have a contradicting understanding of that. In fact, the jtreg documentation here https://openjdk.org/jtreg/tag-spec.html for `@library` tag strongly recommends using `@build` for library classes used in the test:

> In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes. A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled. It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile, and may lead to incomplete recompilation when a test or library code has been modified.

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

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

From lmesnik at openjdk.org  Wed Mar 26 15:43:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Mar 2025 15:43:28 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v3]
In-Reply-To: <Tb8hvQqUelaU5Rz3Cz0Xe2kB4U2sKScMm0cCrE36aGg=.606cce6e-d82b-4b92-85f7-2a185754f02d@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
 <80klpcv184ZiGCa_ARxSz_Kora4CufZ5S9ezYyHCmkc=.1ebc19a2-5b4a-4770-b241-b2c77e3d15c5@github.com>
 <Tb8hvQqUelaU5Rz3Cz0Xe2kB4U2sKScMm0cCrE36aGg=.606cce6e-d82b-4b92-85f7-2a185754f02d@github.com>
Message-ID: <O4LDWFRbgwjFiCysJOhp-irXM3Xlo1E_hD-n5DV6pHQ=.3fd53318-f10b-444b-99e7-00c6748fe1d3@github.com>

On Wed, 26 Mar 2025 15:08:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Leonid,
> 
> Not a code review, but a general review about the proposal.
> 
> > The only reliable fix would be don't use shared class directory at all and compile all libraries for each test.
> 
> By all libraries, do you mean all classes that reside under the directory tree of each of the `@library` that been declared on a specific test definition?
> 
Yes,

> > Although it looks like huge performance overhead, the impact is low.
> 
> The before/after numbers that you posted for the JDK repo look reasonable. JDK isn't the sole user of `jtreg`, but yes I think it's the largest user, so we might have to consider if this change needs to be configurable in some way to allow select projects (like the JDK) to opt-in to this new behaviour.
> 
Hmm, just curious, what are the other users.
> > The libraries are not often compiled using build tag.
> 
> I have a contradicting understanding of that. In fact, the jtreg documentation here https://openjdk.org/jtreg/tag-spec.html for `@library` tag strongly recommends using `@build` for library classes used in the test:
> 
> > In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes. A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled. It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile, and may lead to incomplete recompilation when a test or library code has been modified.

This part of documentation needs to be updated. The main issues is that requirement to use `@build` directive for each package or class used from library by test is overkill. Engineers prefer to rely on implicit compilation. So we have thousands of implicit usage of libraries in our tests. The explicit build is used usually only if test source doesn't depend on the library classes during compilation. Usually, if they are used by classes running with ProcessTools. 

Might be all would work if jtreg disable implicit compilation library dependency and require to cover all classes by build but it overcomplicate tests.

Yes, it is a known and existing problem that "implicit" dependency doesn't call recompilation if library changes only. However, nothing can be done with it right now.

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

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

From lmesnik at openjdk.org  Wed Mar 26 19:18:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Mar 2025 19:18:52 GMT
Subject: RFR: 7902847: Class directory of a test case should be always used
 to compile a library [v4]
In-Reply-To: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
References: <B2mTW5tS651sAHbb1WpoUBDfL1DNJfSQJDUH5X0Thh4=.c79c28a2-fd9f-4ca6-98fc-0f8884e002f6@github.com>
Message-ID: <E4eEDAktwvwwIoGCCRxJ_SLx6h1lglTtssostG6mk9U=.223e580b-c0d3-413c-91c0-884179f7c762@github.com>

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

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

 - doc updated
 - regression test added

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

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

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

  Stats: 169 lines in 7 files changed: 156 ins; 4 del; 9 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  Thu Mar 27 12:28:21 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 27 Mar 2025 12:28:21 GMT
Subject: Integrated: 7903971: Restore propagation of preview flag into library
 code
In-Reply-To: <X87EzsQsHk7kPBIETOLC0X4tN0VtaLG5n16JG4OdYIQ=.ad12e465-cecd-4b40-8333-621a04ca8bea@github.com>
References: <X87EzsQsHk7kPBIETOLC0X4tN0VtaLG5n16JG4OdYIQ=.ad12e465-cecd-4b40-8333-621a04ca8bea@github.com>
Message-ID: <lCyXEauNWbdiYS4EuvUpyD1XuA5Xw2fY1LmapskfkXo=.2b785ff2-7cc0-4905-9214-155f06f596ef@github.com>

On Thu, 13 Mar 2025 14:35:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change restoring the propagation of the preview flag into compilation of library code.
> 
> This will complete the removal of the problematic `LIBRARY.properties` implementation started with [CODETOOLS-7903940](https://bugs.openjdk.org/browse/CODETOOLS-7903940)
> 
> See: https://github.com/openjdk/jtreg/blob/9d253be7d40d9fa4ab671066b959711566942485/src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java#L366

This pull request has now been integrated.

Changeset: d225f878
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/d225f878d5fb4f9cb15bbae0bb795808bb70383e
Stats:     128 lines in 8 files changed: 109 ins; 14 del; 5 mod

7903971: Restore propagation of preview flag into library code

Reviewed-by: mcimadamore

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

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