On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <d...@openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead 
>> of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** 
>> (LazyOutputBuffer) starts a thread in its constructor, so we would need to 
>> add a strange additional constructor parameter to the 
>> `OutputBuffer.of(Process, Charset)` static method, while the printing 
>> through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to 
>> `output buffer.verbose` would make it cleaner, and avoid referencing the 
>> OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini 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 three additional 
> commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 
> 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <li...@openjdk.org>
>  - Initial working solution

Catching up a bit. The use case is for running a test from the commandline 
where the timing of the output seems to be significant to the debugging 
sessions?  It is assumed that the test launches a subprocess and is monitoring 
its state.

Is there an example of the test where this would be used?

The test utilities of OutputAnalyzer may not be what you need. 
They encapsulate a number of behaviors that are readily available using 
ProcessBuilder and Process.

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-3102914137

Reply via email to