From cstein at openjdk.org  Tue Dec  2 11:47:27 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 2 Dec 2025 11:47:27 GMT
Subject: RFR: 7904083: Print fatal error messages to stderr
In-Reply-To: <52QdEtvrjq2yKV4QcLqGKhROC7EKcfzJAjmBBWf0Vi4=.b6146125-c8f9-4349-8a6d-f04d48c6b9c9@github.com>
References: <Cw_ooHhtnB9aJdGfvV3u0DMVbL9VW-VGOUEDav4eQBk=.634bdcb6-1ee3-4c91-a790-7df10e2bf9fb@github.com>
 <sBX7eX74ZvbtlzeqeVQFrQX22wvXSrUeNzTlc_-eYmo=.a342489a-7418-4a74-949f-2684d8d70e90@github.com>
 <52QdEtvrjq2yKV4QcLqGKhROC7EKcfzJAjmBBWf0Vi4=.b6146125-c8f9-4349-8a6d-f04d48c6b9c9@github.com>
Message-ID: <w1mcorDPUaOX46uK8Z9r3OsyhHSikkCbUMRiW0h9wuU=.af042bc8-1e4d-456c-a1eb-f9847d63b040@github.com>

On Fri, 26 Sep 2025 12:47:14 GMT, SendaoYan <syan at openjdk.org> wrote:

> [...] Currently, all normal and abnormal logs are output to stdout, so it's impossible to disable only the normal version output.
 
Printing everything to stdout is something that existing scripts and tools might expect. Changing this will then break those integrations, right?

> [...] check if the current jtreg command works properly.

Can this be tested in way without changing `jtreg`?

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

PR Comment: https://git.openjdk.org/jtreg/pull/290#issuecomment-3601625878

From cstein at openjdk.org  Tue Dec  2 12:03:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 2 Dec 2025 12:03:31 GMT
Subject: RFR: 7904084: Unset javaOpts and jtregOpts in jtreg.sh [v2]
In-Reply-To: <8WJCZd44tfAGAlVfiyZAR_OFOosCwUz0WDOFi23snuI=.de9c7f05-6d32-4f59-b320-89e9cb244af0@github.com>
References: <K4U0-tl4b_m7P2GLdBPm8WMXK7Z9n8AwhQH4D59WoHM=.fb58f7e1-402b-47f7-94ad-ead4f0de53d8@github.com>
 <8WJCZd44tfAGAlVfiyZAR_OFOosCwUz0WDOFi23snuI=.de9c7f05-6d32-4f59-b320-89e9cb244af0@github.com>
Message-ID: <pfwa_8F5ajhrnD3tlisRTkvDTesINF7Z6qcy6_gG9Zo=.55f9d549-fc06-4dc0-9053-8fe0b3672d88@github.com>

On Thu, 20 Nov 2025 08:44:56 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> In jtreg.sh it will combine all the java options and jtreg options in the `for i in "$@"` loop. SHELL use javaOpts and jtregOpts as global varable by default, this means jtreg.sh will receive the value of javaOpts and jtregOpts outside. I think this unexpected.
>> To avoid this siutation, I think we should unset javaOpts and jtregOpts before use it.
>
> SendaoYan 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 jbs7904084
>  - 7904084: Unset javaOpts and jtregOpts in jtreg.sh

Did you see an error when used in combination with another or the same script? If yes, which one(s)?

There's related prior-art in the script for the `DUALCASE` variable. Which is declard and initialized before each use, and `unset` after each use. Would it be possible to the same for `javaOpts` and `jtregOpts`? Or at least `unset` both after use.

Another solution would be to introduce script-`local` variables, right?

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

PR Comment: https://git.openjdk.org/jtreg/pull/291#issuecomment-3601684161

From cstein at openjdk.org  Tue Dec  2 12:08:32 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 2 Dec 2025 12:08:32 GMT
Subject: RFR: 7904101: intermittent failure in StreamsTest.agentvm.ok [v3]
In-Reply-To: <-1mS9h0WdPH0_kP6iNltA57oDfdmDUn2EsSTJeWSi_U=.58e1bb75-0e71-46fd-b6e6-0fd4052e1d6c@github.com>
References: <QbzFya1bkj9PVpOVTW7jITjrSa_aKqR6hdlZYb9nniY=.a9ad023a-0829-4b43-8fc7-dd9f8a867d86@github.com>
 <-1mS9h0WdPH0_kP6iNltA57oDfdmDUn2EsSTJeWSi_U=.58e1bb75-0e71-46fd-b6e6-0fd4052e1d6c@github.com>
Message-ID: <wmKyNCJupzu8uYTv6z7aHfMCRmGMyksW_D8G59l9c-U=.83814a60-4e63-4a77-803a-00ecf83e7763@github.com>

On Mon, 27 Oct 2025 22:00:06 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> FileDescriptor test intermittently fails because the agent's process output capture lacks synchronisation. 
>> 
>> This PR fixes the issue:
>> - Agent VM prints the "process output separator" to stderr and stdout before and after action
>> - The main vm uses the marker to stop reading the stream for the current test result section (or a general agent log)
>> - The main vm restarts reading the log after updating the test section (or clearing it) until the next marker or the process is shut down.
>> 
>> Alternative:
>>  -Disable the test and make no assumptions about contents of the agent vm process output.
>> 
>> Testing: tier1 and tier2 tests on mainline jdk (Ubuntu Linux) in agentvm mode.
>> 
>> 
>> make test TEST=":tier1 :tier2" JTREG="TEST_MODE=agentvm"
>> 
>> ....
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>    jtreg:test/hotspot/jtreg:tier1                     3124  2837     0     0   287   
>>    jtreg:test/jdk:tier1                               2519  2480     0     0    39   
>>    jtreg:test/langtools:tier1                         4670  4660     0     0    10   
>>    jtreg:test/jaxp:tier1                                 0     0     0     0     0   
>>    jtreg:test/lib-test:tier1                            38    38     0     0     0   
>>    jtreg:test/hotspot/jtreg:tier2                      960   913     0     0    47   
>>>> jtreg:test/jdk:tier2                               4455  4220     1     0   234 <<
>>    jtreg:test/langtools:tier2                           14    12     0     0     2   
>>    jtreg:test/jaxp:tier2                               517   516     0     0     1   
>>    jtreg:test/docs:tier2                                 4     0     0     0     4   
>> ==============================
>> TEST FAILURE
>> 
>> 
>> Unrelated failure: test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java
>> 
>> 
>> 
>> 
>> ---------System.out:(98/7409)----------
>> Seed from RandomFactory = 7590698091695474155L
>> [15:02:42.244] config SendReceiveMaxSize.setUp(): success [0ms]
>> [15:02:42.272] test SendReceiveMaxSize.testGetOption(SendReceiveMaxSize$$Lambda/0x00000000450736f8 at 8d234b9, 65507, /10.201.67.1): success [7ms]
>> [15:02:42.273] test SendReceiveMaxSize.testGetOption(SendReceiveMaxSize$$Lambda/0x0000000045073920 at 449629ff, 65507, /10.201.67.1): success [0ms]
>> [15:02:42.273] test SendReceiveMaxSize.testGetOption(SendReceiveMaxSize$$Lamb...
>
> Vladimir Petko has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - fix: create sections in the main thread
>  - chore: propagate timeouts and exceptions
>  - fix: do not synchronize section output
>  - fix: allow marker to appear at the end of the line

> Alternative:
> -Disable the test and make no assumptions about contents of the agent vm process output.

Before looking deeper into the implementation, do I read this correctly, the a test makes "assumptions about contents of the agent vm process output"?

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

PR Comment: https://git.openjdk.org/jtreg/pull/295#issuecomment-3601702583

From syan at openjdk.org  Tue Dec  2 12:32:30 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 2 Dec 2025 12:32:30 GMT
Subject: RFR: 7904084: Unset javaOpts and jtregOpts in jtreg.sh [v2]
In-Reply-To: <pfwa_8F5ajhrnD3tlisRTkvDTesINF7Z6qcy6_gG9Zo=.55f9d549-fc06-4dc0-9053-8fe0b3672d88@github.com>
References: <K4U0-tl4b_m7P2GLdBPm8WMXK7Z9n8AwhQH4D59WoHM=.fb58f7e1-402b-47f7-94ad-ead4f0de53d8@github.com>
 <8WJCZd44tfAGAlVfiyZAR_OFOosCwUz0WDOFi23snuI=.de9c7f05-6d32-4f59-b320-89e9cb244af0@github.com>
 <pfwa_8F5ajhrnD3tlisRTkvDTesINF7Z6qcy6_gG9Zo=.55f9d549-fc06-4dc0-9053-8fe0b3672d88@github.com>
Message-ID: <3vzy-9GeCrm4IfOjw8cH1Ceh8gLbpldfyWm4ANg7LJ4=.d474fbe6-10a2-4362-acd4-3add2ff62246@github.com>

On Tue, 2 Dec 2025 12:01:02 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Did you see an error when used in combination with another or the same script? If yes, which one(s)?

Below command shows this error:

> jtreg -version
jtreg 8.1-dev+0
Installed in /home/yansendao/JDK/tools/jtreg/jtreg-8.1/lib/jtreg.jar
Running on platform version 25.0.1-internal from /home/yansendao/JDK/binary/openjdk/jdk25u.
Built with Java(TM) 2 SDK, Version 25.0.1-internal-987af5af on October 10, 2025.
JT Harness, version 6.0 ea b24 (October 10, 2025)
Java Assembler Tools, version 8.1 ea 01 (October 10, 2025)
TestNG: testng-7.3.0.jar, guice-5.1.0.jar, jcommander-1.82.jar
JUnit: junit-platform-console-standalone-1.13.4.jar

> jtregOpts="ValuesBeforeStartJtreg" jtreg -version
Error: Cannot find file: ValuesBeforeStartJtreg


> There's related prior-art in the script for the `DUALCASE` variable. Which is declard and initialized before each use, and `unset` after each use. Would it be possible to the same for `javaOpts` and `jtregOpts`? Or at least `unset` both after use.

I think `unset javaOpts` is identical to `javaOpts=""`

> Another solution would be to introduce script-`local` variables, right?

`local` illegal outside shell function.

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

PR Comment: https://git.openjdk.org/jtreg/pull/291#issuecomment-3601797729

From cstein at openjdk.org  Tue Dec  2 13:51:49 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 2 Dec 2025 13:51:49 GMT
Subject: RFR: 7904104: intermittent test failure in
 TimeoutDefaultSecondsWaiter
In-Reply-To: <bEk97nwTTIjbzyV9jzY48pgTfsPk5NSLaFJvpw1hn6M=.26aa577b-1604-44ba-bf7a-5f94ee2f2bc7@github.com>
References: <bEk97nwTTIjbzyV9jzY48pgTfsPk5NSLaFJvpw1hn6M=.26aa577b-1604-44ba-bf7a-5f94ee2f2bc7@github.com>
Message-ID: <mPQhjHUn4X8biBsHbM5fLNeVETO4FNHij_b8lrLtV8A=.6dd9da20-ce36-4f52-b716-63e9e53932a2@github.com>

On Tue, 28 Oct 2025 03:09:59 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> `victim.interrupt()` is not needed if the process exits  after the kill signal. 
> This PR only calls interrupt() if the process fails to exit or the wait is interrupted for some reason. 
> 
> This allows TimeoutDefaultSecondsWaiter tests to pass. 
> 
> Alternative: update assertion in TimeoutDefaultSecondsWaiter test.

@jonathan-gibbons and others correct me if I'm reading the comment in `src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java` wrong,

> ```java
> // JDK 1.8 introduces a Process.waitFor(timeout) method which could
> // be used here. We need run on 1.5 so using interrupt() instead.
>
> victim.interrupt();
> ```

 but here it is about to replace:

`int exitCode = process.waitFor();`

with

`int exitCode = process.waitFor(TIMEOUT);`

and remove the custom "victim" timeout thread entirely. Right?

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

PR Comment: https://git.openjdk.org/jtreg/pull/296#issuecomment-3602176456

From cstein at openjdk.org  Tue Dec  2 14:06:56 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 2 Dec 2025 14:06:56 GMT
Subject: RFR: 7904107: AgentOut.othervm.ok should not access
 $(BUILDTESTDIR)/AgentOut.agentvm
In-Reply-To: <cBCzo8OLvIMbrVdSIdLY5zod7PnZY8fnqSzfO14mcJE=.2628f12d-7d4d-4ba1-8b61-f064e3a29cb8@github.com>
References: <cBCzo8OLvIMbrVdSIdLY5zod7PnZY8fnqSzfO14mcJE=.2628f12d-7d4d-4ba1-8b61-f064e3a29cb8@github.com>
Message-ID: <fkxRqb24TGiWRRdXn10cNPm6HZrbKqVvrKJMYtnPbOk=.a848b2cd-4e49-4c1a-88ba-abb573ef6a4f@github.com>

On Tue, 28 Oct 2025 03:23:42 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> AgentOut.othervm.ok tries to access $(BUILDTESTDIR)/AgentOut.agentvm. This should only happen in AgentOut.agentvm.ok. 
> Add a new target to filter log lines that depends on AgentOut.agentvm.ok.
> 
> Note: tests pass on retry[1]. The test failure is caused by [2]
> 
> [1] https://github.com/vpa1977/jtreg/actions/runs/18863066182
> [2] https://github.com/openjdk/jtreg/pull/297

Looks reasonable

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

Marked as reviewed by cstein (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/299#pullrequestreview-3530308429

From cstein at openjdk.org  Tue Dec  2 14:12:17 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 2 Dec 2025 14:12:17 GMT
Subject: RFR: 7904105: intermittent test failure in
 CleanupDirTests.agentvm.conc
In-Reply-To: <WGEdviTCuQCt8O-OUUOVew_mEFVLKn09nQc76y6yEY8=.618db97c-c19f-4181-afdc-33773a508144@github.com>
References: <WGEdviTCuQCt8O-OUUOVew_mEFVLKn09nQc76y6yEY8=.618db97c-c19f-4181-afdc-33773a508144@github.com>
Message-ID: <coobqF6jtUcGkLnJ1pHsjAc6Oj5VssMBOG4w9aSjQ0Q=.b2bffe86-0f32-47b6-bc93-7fc1cec0e73b@github.com>

On Tue, 28 Oct 2025 03:12:34 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> jtharness does not synchronize calls to Observer. Synchronized keyword needs to be added when processing shared state.

This change looks good-enough for the time being.

As @jaikiran said, there's potential to address this in a more fundamental way, but adding those three `synchronized` modifiers a) doesn't hurt, b) seems to address the flaky test issue, and c) doesn't prevent future improvements.

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

Marked as reviewed by cstein (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/297#pullrequestreview-3530334046

From vpetko at openjdk.org  Tue Dec  2 19:50:14 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 2 Dec 2025 19:50:14 GMT
Subject: RFR: 7904101: intermittent failure in StreamsTest.agentvm.ok [v3]
In-Reply-To: <wmKyNCJupzu8uYTv6z7aHfMCRmGMyksW_D8G59l9c-U=.83814a60-4e63-4a77-803a-00ecf83e7763@github.com>
References: <QbzFya1bkj9PVpOVTW7jITjrSa_aKqR6hdlZYb9nniY=.a9ad023a-0829-4b43-8fc7-dd9f8a867d86@github.com>
 <-1mS9h0WdPH0_kP6iNltA57oDfdmDUn2EsSTJeWSi_U=.58e1bb75-0e71-46fd-b6e6-0fd4052e1d6c@github.com>
 <wmKyNCJupzu8uYTv6z7aHfMCRmGMyksW_D8G59l9c-U=.83814a60-4e63-4a77-803a-00ecf83e7763@github.com>
Message-ID: <5qgboGVsxC0GwJSXUIjBVXm1WMBG08LzrAcK2TQ9wEo=.53bc0b28-9072-4057-b380-8e1e90dcb30f@github.com>

On Tue, 2 Dec 2025 12:06:17 GMT, Christian Stein <cstein at openjdk.org> wrote:

> > Alternative:
> > -Disable the test and make no assumptions about contents of the agent vm process output.
> 
> Before looking deeper into the implementation, do I read this correctly, the a test makes "assumptions about contents of the agent vm process output"?

Yes, the test writes to the file descriptor [directly](https://github.com/openjdk/jtreg/blob/a6a32dd7c8250b4c06e904ccc94ffbcd8f009a43/test/streams/FileDescriptorTest.java#L42). The test is ran in the agent mode,  and the agent server is supposed to capture stdout/stderr of the test and add it to the jtr. 
The existing implemention has no synchronization so the log lines can be lost causing intermittent test failures.

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

PR Comment: https://git.openjdk.org/jtreg/pull/295#issuecomment-3603701113

From vpetko at openjdk.org  Tue Dec  2 19:57:31 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 2 Dec 2025 19:57:31 GMT
Subject: RFR: 7904104: intermittent test failure in
 TimeoutDefaultSecondsWaiter
In-Reply-To: <mPQhjHUn4X8biBsHbM5fLNeVETO4FNHij_b8lrLtV8A=.6dd9da20-ce36-4f52-b716-63e9e53932a2@github.com>
References: <bEk97nwTTIjbzyV9jzY48pgTfsPk5NSLaFJvpw1hn6M=.26aa577b-1604-44ba-bf7a-5f94ee2f2bc7@github.com>
 <mPQhjHUn4X8biBsHbM5fLNeVETO4FNHij_b8lrLtV8A=.6dd9da20-ce36-4f52-b716-63e9e53932a2@github.com>
Message-ID: <7bPw_zR8j2L4TAVibGhq4wC2beogM6GuqLHSblwp5nI=.e91f3d26-e9d5-45fe-bc8d-beb2ef738475@github.com>

On Tue, 2 Dec 2025 13:49:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> and remove the custom "victim" timeout thread entirely. Right?

It may still be needed for the edge condition where the process does not exit within the specified timeout[1]. In this case we want to unlock the main thread to continue with the next test.

[1] https://docs.oracle.com/javase/8/docs/api/java/lang/Process.html#waitFor-long-java.util.concurrent.TimeUnit-

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

PR Comment: https://git.openjdk.org/jtreg/pull/296#issuecomment-3603721285

From jpai at openjdk.org  Thu Dec 11 06:43:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Dec 2025 06:43:47 GMT
Subject: RFR: 7904121: jasm usage in jtreg test leads to log messages on stdout
 of jtreg process
Message-ID: <JEXoQGtevJPvyPu6CIIEs2wkq5ulTd8wLW0zRNJt08A=.9e57c697-934d-490c-9def-ad991a5da09d@github.com>

Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904121.

The change here replaces the usage of the deprecated constructors in `org.openjdk.asmtools.jasm.Main` and `org.openjdk.asmtools.jcoder.Main` to their newer counterparts. This allows jtreg the control over where the stdout and stderr  generated by those tools gets written to. 

A new self test has been introduced to verify that the compilation of a jasm file in a jtreg test, generates the expected stdout/stderr sections in the test's report file.

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

Commit messages:
 - close the streams
 - 7904121: jasm usage in jtreg test leads to log messages on stdout of jtreg process

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

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

From cstein at openjdk.org  Thu Dec 11 07:21:02 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 11 Dec 2025 07:21:02 GMT
Subject: RFR: 7904121: jasm usage in jtreg test leads to log messages on
 stdout of jtreg process
In-Reply-To: <JEXoQGtevJPvyPu6CIIEs2wkq5ulTd8wLW0zRNJt08A=.9e57c697-934d-490c-9def-ad991a5da09d@github.com>
References: <JEXoQGtevJPvyPu6CIIEs2wkq5ulTd8wLW0zRNJt08A=.9e57c697-934d-490c-9def-ad991a5da09d@github.com>
Message-ID: <W7RmVOwSXDkxhEwA-yR2P--A_sGCAJwl7JRh5ZAr7Dg=.0525e5b2-798f-4ead-857e-e8f863ef2f35@github.com>

On Thu, 11 Dec 2025 06:35:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904121.
> 
> The change here replaces the usage of the deprecated constructors in `org.openjdk.asmtools.jasm.Main` and `org.openjdk.asmtools.jcoder.Main` to their newer counterparts. This allows jtreg the control over where the stdout and stderr  generated by those tools gets written to. 
> 
> A new self test has been introduced to verify that the compilation of a jasm file in a jtreg test, generates the expected stdout/stderr sections in the test's report file.

Marked as reviewed by cstein (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/301#pullrequestreview-3566062012

From jpai at openjdk.org  Fri Dec 12 02:02:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 02:02:51 GMT
Subject: git: openjdk/jtreg: 7904121: jasm usage in jtreg test leads to log
 messages on stdout of jtreg process
Message-ID: <1547bea9-cf8d-4a5f-8ea8-3bcb28aa4ec1@openjdk.org>

Changeset: 2cffb4d7
Branch: master
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2025-12-12 01:57:40 +0000
URL:       https://git.openjdk.org/jtreg/commit/2cffb4d784a25f016b947a8fbe2b2b62b18e13cd

7904121: jasm usage in jtreg test leads to log messages on stdout of jtreg process

Reviewed-by: cstein

! src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java
= test/jasm/Hello.jasm
+ test/jasm/Jasm.gmk
+ test/jasm/JasmUsageTest.java
= test/jasm/TEST.ROOT


From jpai at openjdk.org  Fri Dec 12 02:00:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 02:00:34 GMT
Subject: RFR: 7904121: jasm usage in jtreg test leads to log messages on
 stdout of jtreg process
In-Reply-To: <JEXoQGtevJPvyPu6CIIEs2wkq5ulTd8wLW0zRNJt08A=.9e57c697-934d-490c-9def-ad991a5da09d@github.com>
References: <JEXoQGtevJPvyPu6CIIEs2wkq5ulTd8wLW0zRNJt08A=.9e57c697-934d-490c-9def-ad991a5da09d@github.com>
Message-ID: <A-wl8sTOB3Nfa6olpqrs_ymD0guIOMLcgMoxfQGCRoE=.a76630ba-cc4c-4913-af13-ee0792620b2a@github.com>

On Thu, 11 Dec 2025 06:35:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904121.
> 
> The change here replaces the usage of the deprecated constructors in `org.openjdk.asmtools.jasm.Main` and `org.openjdk.asmtools.jcoder.Main` to their newer counterparts. This allows jtreg the control over where the stdout and stderr  generated by those tools gets written to. 
> 
> A new self test has been introduced to verify that the compilation of a jasm file in a jtreg test, generates the expected stdout/stderr sections in the test's report file.

Thank you Christian for the review.

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

PR Comment: https://git.openjdk.org/jtreg/pull/301#issuecomment-3644563582

From jpai at openjdk.org  Fri Dec 12 02:00:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 02:00:35 GMT
Subject: Integrated: 7904121: jasm usage in jtreg test leads to log messages on
 stdout of jtreg process
In-Reply-To: <JEXoQGtevJPvyPu6CIIEs2wkq5ulTd8wLW0zRNJt08A=.9e57c697-934d-490c-9def-ad991a5da09d@github.com>
References: <JEXoQGtevJPvyPu6CIIEs2wkq5ulTd8wLW0zRNJt08A=.9e57c697-934d-490c-9def-ad991a5da09d@github.com>
Message-ID: <-LuNbhx8LtVHEnwwAcbrn5IoXroSwAxggKwvDvT7tsY=.94e36aa7-dd21-4a4d-9407-610fd6550000@github.com>

On Thu, 11 Dec 2025 06:35:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904121.
> 
> The change here replaces the usage of the deprecated constructors in `org.openjdk.asmtools.jasm.Main` and `org.openjdk.asmtools.jcoder.Main` to their newer counterparts. This allows jtreg the control over where the stdout and stderr  generated by those tools gets written to. 
> 
> A new self test has been introduced to verify that the compilation of a jasm file in a jtreg test, generates the expected stdout/stderr sections in the test's report file.

This pull request has now been integrated.

Changeset: 2cffb4d7
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/2cffb4d784a25f016b947a8fbe2b2b62b18e13cd
Stats:     145 lines in 5 files changed: 133 ins; 2 del; 10 mod

7904121: jasm usage in jtreg test leads to log messages on stdout of jtreg process

Reviewed-by: cstein

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

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

From jpai at openjdk.org  Fri Dec 12 06:41:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 06:41:20 GMT
Subject: RFR: 7904113: Logging flags cause malformed \uxxxx encoding
Message-ID: <z60-w9RvmaamP15g5Igi5G_hzrW5SLKHWHepjrmZsNU=.4653f1ab-4ac1-4fd7-b446-a9903f0686e2@github.com>

Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904113?

jtreg when running tests against a target JDK, launches a jtreg internal main application - the `com.sun.javatest.regtest.agent.GetJDKProperties` which is expected to return back properties of the target JDK. These properties are expected to be loadable using the `java.util.Properties` class. jtreg launches `GetJDKProperties` as a separate `Process` and then waits for it to complete and expects that `GetJDKProperties` writes out the properties to the standard output of that process. Once that process completes (with an exit code of 0), jtreg then reads the standard output of that process and starts loading each line as a key/value pair property, using the `Properties` class.

It can happen that jtreg launches this `GetJDKProperties` process using additional user specified JVM arguments. So of these JVM arguments may generate additional messages on the process' standard output and those messages don't represent any properties of the target JDK. Furthermore, it's possible that such log messages may not even be loaded using `Properties` class thus leading to exceptions like the ones noted in the linked issue.

The commit in this PR changes the `GetJDKProperties` to write out the properties (and only the properties) to an output file instead of writing it out to standard output of the process. That way, there won't be any interference in the generated output and any unexpected log messages in the launched process. The jtreg side then reads the properties from this output file instead of reading from the standard output of the process. This interaction between jtreg and the launched `GetJDKProperties` is all internal to jtreg and an internal implementation detail, so this change doesn't/shouldn't cause any compatibility concerns.

Given the nature of this change, I haven't added a self test for this. However, I have verified that the original reported issue no longer reproduces with this change (and continues to reproduce without this change). I have also run tier1, tier2, tier3 testing of the current JDK mainline with this change to jtreg and those tests completed without any related issues.

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

Commit messages:
 - 7904113: Logging flags cause malformed \uxxxx encoding

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

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

From jpai at openjdk.org  Fri Dec 12 07:44:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 07:44:25 GMT
Subject: RFR: 7904122: Compilation of jasm files leads to class file version
 warning
Message-ID: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>

Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904122?

The commit here adds `-cv 52.0` as an option when launching the `jasm` tool for compiling `jasm` files through jtreg's `@compile` action. This class file version will be used as the default version if the jasm file doesn't explicitly specify a class file version in it. The use of "-cv" option prevents the warning from being issued.

An existing self test has been updated to verify this change.

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

Commit messages:
 - 7904122: Compilation of jasm files leads to class file version warning

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

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

From cstein at openjdk.org  Fri Dec 12 09:11:32 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 12 Dec 2025 09:11:32 GMT
Subject: RFR: 7904122: Compilation of jasm files leads to class file
 version warning
In-Reply-To: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
References: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
Message-ID: <DyVMI39QQGoDWhsJenTyP1-DEsV086EAnA_W2hWOC7Y=.50d99fa1-6abc-44e7-9582-4b0ba5caa396@github.com>

On Fri, 12 Dec 2025 07:39:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904122?
> 
> The commit here adds `-cv 52.0` as an option when launching the `jasm` tool for compiling `jasm` files through jtreg's `@compile` action. This class file version will be used as the default version if the jasm file doesn't explicitly specify a class file version in it. The use of "-cv" option prevents the warning from being issued.
> 
> An existing self test has been updated to verify this change.

test/jasm/Jasm.gmk line 45:

> 43: 	$(GREP) '\---jasm:' $(@:%.ok=%)/work/JasmUsageTest.jtr > /dev/null
> 44: 	# verify that the warning wasn't printed
> 45: 	$(GREP) 'Warning: Class file version not specified in file or by -cv parameter' \

Would it make sense to (also) look for any other "Warning: ..." messages? ?

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/303#discussion_r2613477749

From jpai at openjdk.org  Fri Dec 12 09:16:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 09:16:36 GMT
Subject: RFR: 7904122: Compilation of jasm files leads to class file
 version warning
In-Reply-To: <DyVMI39QQGoDWhsJenTyP1-DEsV086EAnA_W2hWOC7Y=.50d99fa1-6abc-44e7-9582-4b0ba5caa396@github.com>
References: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
 <DyVMI39QQGoDWhsJenTyP1-DEsV086EAnA_W2hWOC7Y=.50d99fa1-6abc-44e7-9582-4b0ba5caa396@github.com>
Message-ID: <o1Gd3d8aG8yRjGMTMMM-DDGXgCYfgYhBhoTGXhoifZU=.0cd573e8-c355-4ce6-8c87-ec43aea4d380@github.com>

On Fri, 12 Dec 2025 09:08:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904122?
>> 
>> The commit here adds `-cv 52.0` as an option when launching the `jasm` tool for compiling `jasm` files through jtreg's `@compile` action. This class file version will be used as the default version if the jasm file doesn't explicitly specify a class file version in it. The use of "-cv" option prevents the warning from being issued.
>> 
>> An existing self test has been updated to verify this change.
>
> test/jasm/Jasm.gmk line 45:
> 
>> 43: 	$(GREP) '\---jasm:' $(@:%.ok=%)/work/JasmUsageTest.jtr > /dev/null
>> 44: 	# verify that the warning wasn't printed
>> 45: 	$(GREP) 'Warning: Class file version not specified in file or by -cv parameter' \
> 
> Would it make sense to (also) look for any other "Warning: ..." messages? ?

Hello Christian, I wouldn't expect any other warning message and if there is one, I think we shouldn't allow that warning to fail this test. This test is merely interested in verifying that the class file version check warning message is not logged.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/303#discussion_r2613495138

From cstein at openjdk.org  Fri Dec 12 09:23:33 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 12 Dec 2025 09:23:33 GMT
Subject: RFR: 7904122: Compilation of jasm files leads to class file
 version warning
In-Reply-To: <o1Gd3d8aG8yRjGMTMMM-DDGXgCYfgYhBhoTGXhoifZU=.0cd573e8-c355-4ce6-8c87-ec43aea4d380@github.com>
References: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
 <DyVMI39QQGoDWhsJenTyP1-DEsV086EAnA_W2hWOC7Y=.50d99fa1-6abc-44e7-9582-4b0ba5caa396@github.com>
 <o1Gd3d8aG8yRjGMTMMM-DDGXgCYfgYhBhoTGXhoifZU=.0cd573e8-c355-4ce6-8c87-ec43aea4d380@github.com>
Message-ID: <9Ar72U3yFZkwLwbnn52Ovewn6z85H7OzZkdcWPtQHS0=.f8f40982-b626-4c87-90a2-5881247f9947@github.com>

On Fri, 12 Dec 2025 09:14:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jasm/Jasm.gmk line 45:
>> 
>>> 43: 	$(GREP) '\---jasm:' $(@:%.ok=%)/work/JasmUsageTest.jtr > /dev/null
>>> 44: 	# verify that the warning wasn't printed
>>> 45: 	$(GREP) 'Warning: Class file version not specified in file or by -cv parameter' \
>> 
>> Would it make sense to (also) look for any other "Warning: ..." messages? ?
>
> Hello Christian, I wouldn't expect any other warning message and if there is one, I think we shouldn't allow that warning to fail this test. This test is merely interested in verifying that the class file version check warning message is not logged.

Okay.

Yet, with such a broader assertion, we would have caught the issue with compiling `.jasm` files earlier.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/303#discussion_r2613513196

From cstein at openjdk.org  Fri Dec 12 09:35:40 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 12 Dec 2025 09:35:40 GMT
Subject: RFR: 7904122: Compilation of jasm files leads to class file
 version warning
In-Reply-To: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
References: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
Message-ID: <oSAICA7nxbqvzXHSySWa0uZBsWIrSqXHWCkok9ZEMQo=.ae5a049a-2d49-413a-923b-94cc52591c10@github.com>

On Fri, 12 Dec 2025 07:39:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904122?
> 
> The commit here adds `-cv 52.0` as an option when launching the `jasm` tool for compiling `jasm` files through jtreg's `@compile` action. This class file version will be used as the default version if the jasm file doesn't explicitly specify a class file version in it. The use of "-cv" option prevents the warning from being issued.
> 
> An existing self test has been updated to verify this change.

Marked as reviewed by cstein (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/303#pullrequestreview-3571057368

From jpai at openjdk.org  Fri Dec 12 09:39:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 09:39:42 GMT
Subject: RFR: 7904122: Compilation of jasm files leads to class file
 version warning
In-Reply-To: <9Ar72U3yFZkwLwbnn52Ovewn6z85H7OzZkdcWPtQHS0=.f8f40982-b626-4c87-90a2-5881247f9947@github.com>
References: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
 <DyVMI39QQGoDWhsJenTyP1-DEsV086EAnA_W2hWOC7Y=.50d99fa1-6abc-44e7-9582-4b0ba5caa396@github.com>
 <o1Gd3d8aG8yRjGMTMMM-DDGXgCYfgYhBhoTGXhoifZU=.0cd573e8-c355-4ce6-8c87-ec43aea4d380@github.com>
 <9Ar72U3yFZkwLwbnn52Ovewn6z85H7OzZkdcWPtQHS0=.f8f40982-b626-4c87-90a2-5881247f9947@github.com>
Message-ID: <KGgjRDMPdVYVCbrf51cQrNFF1-5R-mu6AUYFFuQj4Hc=.489b6c28-a655-48f1-a93a-09028b766527@github.com>

On Fri, 12 Dec 2025 09:20:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Hello Christian, I wouldn't expect any other warning message and if there is one, I think we shouldn't allow that warning to fail this test. This test is merely interested in verifying that the class file version check warning message is not logged.
>
> Okay.
> 
> Yet, with such a broader assertion, we would have caught the issue with compiling `.jasm` files earlier.

We would have to narrow down the "grep" to specific lines in that jtr file to be sure that only warning(s) from the `@compile <file>.jasm` action are considered in that check. That will require some grep skills. I can experiment with it, if you prefer we check for other warnings too.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/303#discussion_r2613563130

From vpetko at openjdk.org  Mon Dec 15 07:23:34 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 15 Dec 2025 07:23:34 GMT
Subject: RFR: 7904104: intermittent test failure in
 TimeoutDefaultSecondsWaiter
In-Reply-To: <bEk97nwTTIjbzyV9jzY48pgTfsPk5NSLaFJvpw1hn6M=.26aa577b-1604-44ba-bf7a-5f94ee2f2bc7@github.com>
References: <bEk97nwTTIjbzyV9jzY48pgTfsPk5NSLaFJvpw1hn6M=.26aa577b-1604-44ba-bf7a-5f94ee2f2bc7@github.com>
Message-ID: <4aAEEtu8rzVNTDPk9KZdJ2m8KJs2gTOXsE5Tucyq_yo=.7e233fea-a9ca-4f19-b267-8e3a8f703bb3@github.com>

On Tue, 28 Oct 2025 03:09:59 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> `victim.interrupt()` is not needed if the process exits  after the kill signal. 
> This PR only calls interrupt() if the process fails to exit or the wait is interrupted for some reason. 
> 
> This allows TimeoutDefaultSecondsWaiter tests to pass. 
> 
> Alternative: update assertion in TimeoutDefaultSecondsWaiter test.

Closing PR, @jaikiran is working on the fix, see https://bugs.openjdk.org/browse/CODETOOLS-7904103

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

PR Comment: https://git.openjdk.org/jtreg/pull/296#issuecomment-3653985998

From vpetko at openjdk.org  Mon Dec 15 07:23:35 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 15 Dec 2025 07:23:35 GMT
Subject: Withdrawn: 7904104: intermittent test failure in
 TimeoutDefaultSecondsWaiter
In-Reply-To: <bEk97nwTTIjbzyV9jzY48pgTfsPk5NSLaFJvpw1hn6M=.26aa577b-1604-44ba-bf7a-5f94ee2f2bc7@github.com>
References: <bEk97nwTTIjbzyV9jzY48pgTfsPk5NSLaFJvpw1hn6M=.26aa577b-1604-44ba-bf7a-5f94ee2f2bc7@github.com>
Message-ID: <N3_2zdsO3V0QV-V4zMmxHfjwomLN52p2TCgcEnHG-aM=.faa99f8d-a7c7-4087-8e4e-ab7fcb7993bc@github.com>

On Tue, 28 Oct 2025 03:09:59 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> `victim.interrupt()` is not needed if the process exits  after the kill signal. 
> This PR only calls interrupt() if the process fails to exit or the wait is interrupted for some reason. 
> 
> This allows TimeoutDefaultSecondsWaiter tests to pass. 
> 
> Alternative: update assertion in TimeoutDefaultSecondsWaiter test.

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Tue Dec 16 10:15:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Dec 2025 10:15:19 GMT
Subject: RFR: 7904122: Compilation of jasm files leads to class file
 version warning
In-Reply-To: <KGgjRDMPdVYVCbrf51cQrNFF1-5R-mu6AUYFFuQj4Hc=.489b6c28-a655-48f1-a93a-09028b766527@github.com>
References: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
 <DyVMI39QQGoDWhsJenTyP1-DEsV086EAnA_W2hWOC7Y=.50d99fa1-6abc-44e7-9582-4b0ba5caa396@github.com>
 <o1Gd3d8aG8yRjGMTMMM-DDGXgCYfgYhBhoTGXhoifZU=.0cd573e8-c355-4ce6-8c87-ec43aea4d380@github.com>
 <9Ar72U3yFZkwLwbnn52Ovewn6z85H7OzZkdcWPtQHS0=.f8f40982-b626-4c87-90a2-5881247f9947@github.com>
 <KGgjRDMPdVYVCbrf51cQrNFF1-5R-mu6AUYFFuQj4Hc=.489b6c28-a655-48f1-a93a-09028b766527@github.com>
Message-ID: <lc8NXfgnqlSqETGbn_PGkSxhrBGOv3UOQMva3y7yO4I=.63b7b608-6fe9-440d-8861-eb614b86fa33@github.com>

On Fri, 12 Dec 2025 09:36:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Okay.
>> 
>> Yet, with such a broader assertion, we would have caught the issue with compiling `.jasm` files earlier.
>
> We would have to narrow down the "grep" to specific lines in that jtr file to be sure that only warning(s) from the `@compile <file>.jasm` action are considered in that check. That will require some grep skills. I can experiment with it, if you prefer we check for other warnings too.

I spoke to Christian about this and we decided to go ahead with the integration of this PR in the current form. Thank you Christian for the review.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/303#discussion_r2622645020

From jpai at openjdk.org  Tue Dec 16 10:17:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Dec 2025 10:17:40 GMT
Subject: Integrated: 7904122: Compilation of jasm files leads to class file
 version warning
In-Reply-To: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
References: <gIfHGaSt_JreZkeqqYru4y7cd0SHGVpCLFgXyZeH-pE=.6be89bae-cb05-488a-bb34-03640908d411@github.com>
Message-ID: <C_gHg0AjY6_AUv7hRPx7DmZedkMWW5WxvU9YoXygKFU=.82af0ea2-111f-4f91-bdf3-e9c99632c9a3@github.com>

On Fri, 12 Dec 2025 07:39:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904122?
> 
> The commit here adds `-cv 52.0` as an option when launching the `jasm` tool for compiling `jasm` files through jtreg's `@compile` action. This class file version will be used as the default version if the jasm file doesn't explicitly specify a class file version in it. The use of "-cv" option prevents the warning from being issued.
> 
> An existing self test has been updated to verify this change.

This pull request has now been integrated.

Changeset: 2534e56c
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/2534e56cf8600b8491283904bcab0d85c0c1fd08
Stats:     24 lines in 2 files changed: 15 ins; 0 del; 9 mod

7904122: Compilation of jasm files leads to class file version warning

Reviewed-by: cstein

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

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

From jpai at openjdk.org  Tue Dec 16 10:19:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Dec 2025 10:19:37 GMT
Subject: git: openjdk/jtreg: 7904122: Compilation of jasm files leads to class
 file version warning
Message-ID: <4365ebaf-992e-4b6a-8351-1456775f5633@openjdk.org>

Changeset: 2534e56c
Branch: master
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2025-12-16 10:15:05 +0000
URL:       https://git.openjdk.org/jtreg/commit/2534e56cf8600b8491283904bcab0d85c0c1fd08

7904122: Compilation of jasm files leads to class file version warning

Reviewed-by: cstein

! src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java
! test/jasm/Jasm.gmk


From cstein at openjdk.org  Wed Dec 17 07:30:32 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 17 Dec 2025 07:30:32 GMT
Subject: RFR: 7904113: Logging flags cause malformed \uxxxx encoding
In-Reply-To: <z60-w9RvmaamP15g5Igi5G_hzrW5SLKHWHepjrmZsNU=.4653f1ab-4ac1-4fd7-b446-a9903f0686e2@github.com>
References: <z60-w9RvmaamP15g5Igi5G_hzrW5SLKHWHepjrmZsNU=.4653f1ab-4ac1-4fd7-b446-a9903f0686e2@github.com>
Message-ID: <BiZLmFXyPyx1JVbhMcGMfebu6nqhjRgM4AW6AmqoYYI=.8e0ada0c-e793-4321-9671-6bd5e7549433@github.com>

On Fri, 12 Dec 2025 06:33:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904113?
> 
> jtreg when running tests against a target JDK, launches a jtreg internal main application - the `com.sun.javatest.regtest.agent.GetJDKProperties` which is expected to return back properties of the target JDK. These properties are expected to be loadable using the `java.util.Properties` class. jtreg launches `GetJDKProperties` as a separate `Process` and then waits for it to complete and expects that `GetJDKProperties` writes out the properties to the standard output of that process. Once that process completes (with an exit code of 0), jtreg then reads the standard output of that process and starts loading each line as a key/value pair property, using the `Properties` class.
> 
> It can happen that jtreg launches this `GetJDKProperties` process using additional user specified JVM arguments. So of these JVM arguments may generate additional messages on the process' standard output and those messages don't represent any properties of the target JDK. Furthermore, it's possible that such log messages may not even be loaded using `Properties` class thus leading to exceptions like the ones noted in the linked issue.
> 
> The commit in this PR changes the `GetJDKProperties` to write out the properties (and only the properties) to an output file instead of writing it out to standard output of the process. That way, there won't be any interference in the generated output and any unexpected log messages in the launched process. The jtreg side then reads the properties from this output file instead of reading from the standard output of the process. This interaction between jtreg and the launched `GetJDKProperties` is all internal to jtreg and an internal implementation detail, so this change doesn't/shouldn't cause any compatibility concerns.
> 
> Given the nature of this change, I haven't added a self test for this. However, I have verified that the original reported issue no longer reproduces with this change (and continues to reproduce without this change). I have also run tier1, tier2, tier3 testing of the current JDK mainline with this change to jtreg and those tests completed without any related issues.

Changes looks good.

Approving under the assumption that jtreg is the only "user" of this program.

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

Marked as reviewed by cstein (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/302#pullrequestreview-3586369166

From jpai at openjdk.org  Wed Dec 17 09:23:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Dec 2025 09:23:01 GMT
Subject: RFR: 7904113: Logging flags cause malformed \uxxxx encoding
In-Reply-To: <z60-w9RvmaamP15g5Igi5G_hzrW5SLKHWHepjrmZsNU=.4653f1ab-4ac1-4fd7-b446-a9903f0686e2@github.com>
References: <z60-w9RvmaamP15g5Igi5G_hzrW5SLKHWHepjrmZsNU=.4653f1ab-4ac1-4fd7-b446-a9903f0686e2@github.com>
Message-ID: <Mw_V7loT2fhsxI7U1i_ciWnPd8_SraKXTYN-SUEp2lc=.f5936257-6ea8-413b-aa90-2a0a5a4c71a0@github.com>

On Fri, 12 Dec 2025 06:33:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904113?
> 
> jtreg when running tests against a target JDK, launches a jtreg internal main application - the `com.sun.javatest.regtest.agent.GetJDKProperties` which is expected to return back properties of the target JDK. These properties are expected to be loadable using the `java.util.Properties` class. jtreg launches `GetJDKProperties` as a separate `Process` and then waits for it to complete and expects that `GetJDKProperties` writes out the properties to the standard output of that process. Once that process completes (with an exit code of 0), jtreg then reads the standard output of that process and starts loading each line as a key/value pair property, using the `Properties` class.
> 
> It can happen that jtreg launches this `GetJDKProperties` process using additional user specified JVM arguments. So of these JVM arguments may generate additional messages on the process' standard output and those messages don't represent any properties of the target JDK. Furthermore, it's possible that such log messages may not even be loaded using `Properties` class thus leading to exceptions like the ones noted in the linked issue.
> 
> The commit in this PR changes the `GetJDKProperties` to write out the properties (and only the properties) to an output file instead of writing it out to standard output of the process. That way, there won't be any interference in the generated output and any unexpected log messages in the launched process. The jtreg side then reads the properties from this output file instead of reading from the standard output of the process. This interaction between jtreg and the launched `GetJDKProperties` is all internal to jtreg and an internal implementation detail, so this change doesn't/shouldn't cause any compatibility concerns.
> 
> Given the nature of this change, I haven't added a self test for this. However, I have verified that the original reported issue no longer reproduces with this change (and continues to reproduce without this change). I have also run tier1, tier2, tier3 testing of the current JDK mainline with this change to jtreg and those tests completed without any related issues.

Thank you for the review Christian. I have looked for the usages of `GetJDKProperties` and from what I can see it appears to be all internal in jtreg itself.

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

PR Comment: https://git.openjdk.org/jtreg/pull/302#issuecomment-3664406847

From jpai at openjdk.org  Wed Dec 17 09:23:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Dec 2025 09:23:02 GMT
Subject: Integrated: 7904113: Logging flags cause malformed \uxxxx encoding
In-Reply-To: <z60-w9RvmaamP15g5Igi5G_hzrW5SLKHWHepjrmZsNU=.4653f1ab-4ac1-4fd7-b446-a9903f0686e2@github.com>
References: <z60-w9RvmaamP15g5Igi5G_hzrW5SLKHWHepjrmZsNU=.4653f1ab-4ac1-4fd7-b446-a9903f0686e2@github.com>
Message-ID: <5_4Pi7GGjRX1YoRPQ48ClCeB7iG8Ia8x1Jg6A5wjP5A=.3f2079fe-fcda-4d88-a92a-0b726b2b5059@github.com>

On Fri, 12 Dec 2025 06:33:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/CODETOOLS-7904113?
> 
> jtreg when running tests against a target JDK, launches a jtreg internal main application - the `com.sun.javatest.regtest.agent.GetJDKProperties` which is expected to return back properties of the target JDK. These properties are expected to be loadable using the `java.util.Properties` class. jtreg launches `GetJDKProperties` as a separate `Process` and then waits for it to complete and expects that `GetJDKProperties` writes out the properties to the standard output of that process. Once that process completes (with an exit code of 0), jtreg then reads the standard output of that process and starts loading each line as a key/value pair property, using the `Properties` class.
> 
> It can happen that jtreg launches this `GetJDKProperties` process using additional user specified JVM arguments. So of these JVM arguments may generate additional messages on the process' standard output and those messages don't represent any properties of the target JDK. Furthermore, it's possible that such log messages may not even be loaded using `Properties` class thus leading to exceptions like the ones noted in the linked issue.
> 
> The commit in this PR changes the `GetJDKProperties` to write out the properties (and only the properties) to an output file instead of writing it out to standard output of the process. That way, there won't be any interference in the generated output and any unexpected log messages in the launched process. The jtreg side then reads the properties from this output file instead of reading from the standard output of the process. This interaction between jtreg and the launched `GetJDKProperties` is all internal to jtreg and an internal implementation detail, so this change doesn't/shouldn't cause any compatibility concerns.
> 
> Given the nature of this change, I haven't added a self test for this. However, I have verified that the original reported issue no longer reproduces with this change (and continues to reproduce without this change). I have also run tier1, tier2, tier3 testing of the current JDK mainline with this change to jtreg and those tests completed without any related issues.

This pull request has now been integrated.

Changeset: 433d2ba8
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/433d2ba84730dccfb7c349571d28f0a8c8397f5d
Stats:     75 lines in 2 files changed: 47 ins; 21 del; 7 mod

7904113: Logging flags cause malformed \uxxxx encoding

Reviewed-by: cstein

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

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