4 ms·

Clickbait title IMO. Essentially Java presents an abstraction and whether the underlying I/O is truly async or emulated depends on the OS. However, such a desig

Clickbait title IMO. Essentially Java presents an abstraction and whether the underlying I/O is truly async or emulated depends on the OS. However, such a design allows them to change the underlying implementation to an OS async API at a later time (example: io_uring on linux). At most, perhaps it would be nice if there was an API to query whether it is truly async or not, but most code is going to want it to "just work" and know their code will take advantage of underlying async I/O, when available. Post from mailing list from a couple years ago, for example: https://mail.openjdk.org/pipermail/loom-dev/2021-November/003125.html https://mail.openjdk.org/pipermail/loom-dev/2021-November/00...

javier2 3y ago
Yeah, this. It will be async when implemented like async on target platform
- xxs 3y ago
  I doubt, as that would break any FileChannel.write(ByteBuffer) that expects the buffer to be consumed (remaining()==0) I suppose it's possible to create a new set of API or augment the existing ones not to use thread pool, still rather unlikely. Also it'd require a general widely supported async from the OS, incl. Windows
  - twic 3y ago
    > I doubt, as that would break any FileChannel.write(ByteBuffer) that expects the buffer to be consumed (remaining()==0) You can't expect that with AsynchronousFileChannel::write at the moment, though, because the buffer is consumed on a background thread. As the docs say [1]: > Buffers are not safe for use by multiple concurrent threads so care should be taken to not access the buffer until the operation has completed. And as the article says, on Windows, these writes are "truly" async at the OS level, so portable code already needs to deal with that. [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/channels/AsynchronousByteChannel.html#write(java.nio.ByteBuffer,A,java.nio.channels.CompletionHandler) https://docs.oracle.com/en/java/javase/17/docs/api/java.base...
de6u99er 3y ago
[flagged]

javier2 3y ago

Yeah, this. It will be async when implemented like async on target platform

xxs 3y ago
I doubt, as that would break any FileChannel.write(ByteBuffer) that expects the buffer to be consumed (remaining()==0) I suppose it's possible to create a new set of API or augment the existing ones not to use thread pool, still rather unlikely. Also it'd require a general widely supported async from the OS, incl. Windows
- twic 3y ago
  > I doubt, as that would break any FileChannel.write(ByteBuffer) that expects the buffer to be consumed (remaining()==0) You can't expect that with AsynchronousFileChannel::write at the moment, though, because the buffer is consumed on a background thread. As the docs say [1]: > Buffers are not safe for use by multiple concurrent threads so care should be taken to not access the buffer until the operation has completed. And as the article says, on Windows, these writes are "truly" async at the OS level, so portable code already needs to deal with that. [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/channels/AsynchronousByteChannel.html#write(java.nio.ByteBuffer,A,java.nio.channels.CompletionHandler) https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

de6u99er 3y ago

[flagged]