InputStream/OutputStream concurrency guarantees

[Pavel Rappo]

In the absence of "frozen arrays" -- which I'm not even sure could be
useful here -- we cannot guarantee that a shared byte[] passed to
OutputStream.write is not meddled with from outside, no matter if
synchronization or defensive copy is used. To clarify the latter
point: the array may be changed while it's being copied, which is no
different from it being changed while it is being written from.

If someone is flipping bytes while OutputStream.write has not yet
returned, then I reckon it's a programming bug or an adversarial
attack, which was probably enabled by such bug. Not sure if there was
any other answer expected.

-Pavel

On Mon, Oct 27, 2025 at 5:02 PM Alan Bateman <alan.bateman at oracle.com> wrote:
>
>
>
> On 27/10/2025 11:47, Pavel Rappo wrote:
>
> The specification of the read/write methods, their classes, and the
> package is silent on multithreading. In which case you should always
> assume that the methods are **not** thread-safe.
>
> Right, although there are some APIs that do specify that input or output streams are safe for used by concurrent threads, e.g. the input/output streams returned by the Channels class that support interop between channels and input/output streams.
>
> Another more subtle aspect to the topic is async close. With many input/output streams it doesn't make any sense to attempt to use them from concurrent threads but async close when there is a blocker read/writer is something that has to be supported in some cases.
>
> In any access, I read Florian's mail as asking something else. I read the mail as concurrent access to the byte[], e.g. someone flipping bytes while someone is calling write.
>
> -Alan