Also, since there aren't any consistency effects in place, it is not
deterministic which changes made by the writer would be seen by the
reader/copier.
On 2025-10-27 18:35, Pavel Rappo wrote:
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
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
