Hi gigs, Currently, the Android File API does not ...

# android

[Breaker ACT]

Hi gigs,
Currently, the Android File API does not yet support the suspend feature. Annotating a function with suspend doesn’t add much value.
On the other hand, Java 21+ has Virtual Threads. The JVM automatically detects IO operations, suspends the operation, and resumes the virtual thread once the result is ready.
This leads me to the view that when reading multiple files simultaneously, Java will perform better than Kotlin.
Please correct me if I’m wrong.

[CLOVIS]

Virtual threads are more lightweight than coroutines to read files, yes. You can use virtual threads from Kotlin, or even within coroutines with a special dispatcher, so it's not a language difference.

[Breaker ACT]

I don't think it is something more lightweight, it is more likely the capability.

You can use virtual threads from Kotlin,

Yes, but it isn't available for Android yet, right ?

[CLOVIS]

That I don't know, I don't do mobile. I'm just saying, this doesn't make a particular language than another, since they can both use this technology equally.

[Breaker ACT]

Yes, you're right.
But I mentioned Android File API specifically 🙂

[CLOVIS]

Thus the answer on Android is: it doesn't matter since virtual threads aren't available

[CLOVIS]

Note that if there is a non-blocking file API then that is the optimal speed, whether you use it from coroutines or virtual threads won't make it faster.

[Breaker ACT]

Nah, I don't think so.
If the IO operation is not supported with suspend keyword, the coroutine scope will be blocked until get the result. The coroutine scope won't be idle during that time.

Whereas with Java VT, JVM can auto detect the IO operation -> it can help the VT idle during waiting time -> less waste and better throughput.

[CLOVIS]

That is true for blocking I/O, yes, because the JVM can replace blocking I/O called from a virtual-thread into non-blocking I/O at the OS-level.

If you could do non-blocking I/O yourself (which you can do for network sockets, but I'm not sure for files) then virtual threads wouldn't provide meaningful benefits

[ephemient]

non-ancient versions of Android do have AsynchronousFileChannel

[ephemient]

however Android is based on Linux and Linux doesn't have good aio, so that ends up using another thread pool for I/O