8191441: (Process) add Readers and Writer access to java.lang.Process streams #4134
Conversation
|
/csr |
|
👋 Welcome back rriggs! A progress list of the required criteria for merging this PR into |
openjdk
bot
added
rfr
|
@RogerRiggs this pull request will not be integrated until the CSR request JDK-8191490 for issue JDK-8191441 has been approved. |
|
@RogerRiggs The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
|
I've added the same comment on the bug itself. |
Good point, but... PrintStream does also and it is used frequently for Stdout and Stderr. OutputStreamWriter would be a better choice with that in mind. It does not have the convenience methods for converting various types to strings but would not hide the exceptions. Developers could wrap it in a PrintWriter to get the convenience and take on the responsibility of dealing with exceptions by polling. |
|
Mailing list message from Bernd Eckenfels on core-libs-dev: Hello, Hm, how is that list used? - StandardCharaet.ISO_8859_1 is a guaranteed Charset for JVM, and since the encoding is done in Java it should be fine. Added benefit is, it?s 8bit transparent. As for OS there is not a single standard charset (ebcdic vs latin families) but ASCII is probably the widest available (with latin1 variants to follow) -- On Thu, 20 May 2021 20:42:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:
Is there a safe subset?
Right, dead code now without host dependencies.
Should be removed, the tests work because they set sun.stdout/stderr.encoding. ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 |
1 similar comment
|
Mailing list message from Bernd Eckenfels on core-libs-dev: Hello, Hm, how is that list used? - StandardCharaet.ISO_8859_1 is a guaranteed Charset for JVM, and since the encoding is done in Java it should be fine. Added benefit is, it?s 8bit transparent. As for OS there is not a single standard charset (ebcdic vs latin families) but ASCII is probably the widest available (with latin1 variants to follow) -- On Thu, 20 May 2021 20:42:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:
Is there a safe subset?
Right, dead code now without host dependencies.
Should be removed, the tests work because they set sun.stdout/stderr.encoding. ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 |
|
Mailing list message from Roger Riggs on core-libs-dev: Hi, The list is used to test the inputReader and errorReader methods that The child process is launched with -Dsun.stdout.encoding and The test for the native charset uses only the native encoding in the Thanks, Roger On 5/20/21 5:30 PM, Bernd Eckenfels wrote: |
1 similar comment
|
Mailing list message from Roger Riggs on core-libs-dev: Hi, The list is used to test the inputReader and errorReader methods that The child process is launched with -Dsun.stdout.encoding and The test for the native charset uses only the native encoding in the Thanks, Roger On 5/20/21 5:30 PM, Bernd Eckenfels wrote: |
yes, instead of OutputStreamWriter, i wonder if BufferedWriter is not better given that reader part uses BufferedReader and that is mirror java.nio.file.Files which also uses BufferedReader/BufferedWriter as types for the pair reader/writer. |
|
Mailing list message from Roger Riggs on core-libs-dev: Hi, Yes, I'm testing BufferedWriter-> OutputStreamWriter now. Roger On 5/21/21 5:23 PM, R?mi Forax wrote: |
|
The updated proposal looks reasonable, as does the names of the methods. I think the javadoc will need to specify how malformed or unmappable byte sequence are handled. The implNote does document that it uses InputStreamReader so this means that erroneous input is replaced but this isn't normative text. It may be useful to specify how these methods are intended to work when the process has terminated. I realise the existing getXXXX aren't clear on this point and maybe they should. The API note that warns about unpredictable behavior then trying to use both the byte and character stream probably needs to go into the existing methods too. NPE will need to be documented as I don't think the Process class description has a statement to avoid clutter in the method descriptions. You will eventually need to add the @SInCE javadoc tag too. Is there more test coverage to come? I don't see tests that exercise the redirect cases or NPE. The test updates includes an adjustment to how SerialFilterTest is run - is that meant to be included? A formatting nit is that the line lengths are very really long compared to the rest of the source file. |
…ding to the 1-arg method with a charset, added tests for Redirect cases where the streams are null-input or null-output streams.
|
Thanks for the comments, most are addressed.
On the question of process termination behavior, I'm not sure what can be said that could be specification. I need to address what happens when these methods are called more than once. |
I think the javadoc could set expectations that the behavior when the process has terminated, and streams have not been redirected, is unspecified. Reading from the process output/error streams may read some or no bytes/characters. |
|
The updated javadoc addresses most of my points. The clarification to inputReader/errorReader about malformed input looks good but we will need the equivalent in outputWriter for the unmappable character case. |
Repeated calls to inputReader, errorReader, and outputWriter now return the same instance and check for inconsistent charset argument Added warnings about concurrently use of input/output streams and readers/writers.
|
Process is abstract. Is there any use for these new methods to be overridden? |
| * This is equivalent to: | ||
| * {@code | ||
| * return new BufferedReader(new InputStreamReader(getInputStream(), charset)); | ||
| * } |
There was a problem hiding this comment.
Does not seem to be equivalent any longer. Also, should it describe the behavior that it rejects the different Charset after the first invocation?
| * @implNote | ||
| * This is equivalent to: | ||
| * {@code | ||
| * return new BufferedReader(new InputStreamReader(getErrorStream(), charset)); | ||
| * } |
There was a problem hiding this comment.
Same comment in inputReader(Charset) stands here too.
It's not clear to me that it is useful to extend Process outside of the JDK. Testing, wrapping, ...? It feels like this class wants to be sealed. Maybe we should look at deprecating the no-arg constructor, like Joe did recently with AccessibleObject. |
There are subclasses, even in the test suite, see ProcessTools, so its too late to seal it; |
|
|
||
| // Readers and Writers created for this process; so repeated calls return the same object | ||
| // All updates must be done while synchronized on this Process. | ||
| private BufferedWriter outputWriter = null; |
There was a problem hiding this comment.
No need to explicitly initialise all these fields to null.
| * @apiNote | ||
| * Use {@link #getOutputStream} and {@link #outputWriter} with extreme care. | ||
| * Output to the {@code BufferedWriter} may be held in the buffer until | ||
| * {@linkplain BufferedWriter#flush flush} is called. |
There was a problem hiding this comment.
I think this will need a bit of wordsmithing to make it clear that its the usage of both streams for the same Process requires great care (as it stands, it reads like the usage of either method is dangerous).
| * <p>This method delegates to {@link #inputReader(Charset)} using the | ||
| * {@link Charset} named by the {@code native.encoding} | ||
| * system property or the {@link Charset#defaultCharset()} if the | ||
| * {@code native.encoding} is not supported. |
There was a problem hiding this comment.
"if the native.encoding is not supported". I think this needs an adjustment to make it clearer that the default charset is used when the value of native.encoding is not a valid charset name.
| outputWriter = new BufferedWriter(new OutputStreamWriter(getOutputStream(), charset)); | ||
| } else { | ||
| if (!outputCharset.equals(charset)) | ||
| throw new IllegalArgumentException("BufferedWriter was created with charset: " + outputCharset); |
There was a problem hiding this comment.
I'm not sure that IAE is the right exception here, I think it's closer to IllegalStateException because the first usage of outputWriter has the side effect of setting the charset for the Process's writer. Another option here is to just put it into the "unpredictable" bucket that is using getOutputStream and outputWriter at the same time. In that case, it could just return a new BufferedWriter when it doesn't match the charset of the first usage.
api notes about useing both writers and streams
| * The {@code BufferedReader} reads and buffers characters from the InputStreamReader. | ||
| * | ||
| * <p>The first call to this method creates the {@link BufferedReader BufferedReader}, | ||
| * if called again with the same {@code charset} the same {@code BufferedReader} is returned. |
There was a problem hiding this comment.
"the same BufferedReader is returned" - a suggestion here to rephrase this to "then the BufferedReader returned by the first call is returned".
|
@RogerRiggs This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 252 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
|
/integrate |
openjdk
bot
added
integrated
|
@RogerRiggs Since your change was applied there have been 253 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 81600dc. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process.
The Charset used to encode and decode characters to bytes can be specified or use the
operating system native encoding as is available from the "native.encoding" system property.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134$ git checkout pull/4134Update a local copy of the PR:
$ git checkout pull/4134$ git pull https://git.openjdk.java.net/jdk pull/4134/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4134View PR using the GUI difftool:
$ git pr show -t 4134Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4134.diff