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 <[email protected]> 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
