On 4/14/25 11:52 PM, Cay Horstmann wrote:
* How exactly do I use getInputStream()/inputReader() with *extreme care*, as the
API doc warns me?
Ah. This is referring to the following note in the Process.getInputStream()
method spec:
API Note:
Use getInputStream() and inputReader() with extreme care. The
BufferedReader may have buffered input from the input stream.
The issue here is that the the inputReader is some Reader implementation (presumably
a BufferedReader) wrapped around the same InputStream as returned by
getInputStream(). If a program interleaves operations on the InputStream with
operations on the Reader, it's unspecified which bytes will go where, and the
results probably won't be useful.
(This is the same issue is wrapping System.in with a
InputStreamReader/BufferedReader or with a Scanner, using them, and then going back
to System.in to read more bytes.)
Even setting aside BufferedReader, any CharsetDecoder is allowed to buffer "extra"
bytes from its input. Thus, mixing operations on a Reader and an underlying
InputStream is inherently ill-defined. Essentially if you want to read bytes, use
the InputStream, but if you want characters, use a Reader, and you can't mix them.
Anyway the wording here is quite vague and should be clarified. It should also be
made normative, and a similar clause should be added to inputReader(). And maybe
elsewhere.
**
There is a *separate* issue discussed elsewhere on this thread, which is what's
necessary to make sure any resources associated with Process are cleaned up
properly. We've observed that the Unix *implementation* cleans up pipes when the
subprocess terminates... but this doesn't seem to be supported by the specs. So
there's another set of issues to deal with, and possible enhancements to let
applications perform cleanup more reliably.
s'marks
