sad to see it's just nio's APIs

# coroutines

[jw]

sad to see it's just nio's APIs

[orangy]

Can you propose something different/better/interesting?

[jw]

I tend to prefer Okio. We're building a cross-platform Kotlin version. It'll eventually be suspendable if coroutine library support becomes cross-platform.

[orangy]

Is there a design doc or something justifying the difference? Not opposing, just curious

[jw]

I gave a talk a few years ago which covered why java.io.InputStream is horribly designed. We haven't really talked about java.nio anywhere though. It's probably worth a blog post.

[orangy]

That would be awesome!

[kenkyee]

I'd vote okio as well...it's a de-facto standard on Android.
Reminds me of Spring's odd choice of Reactor instead of RxJava2...

[orangy]

As if the whole world is only Android 🙂 I believe requirements for IO on a server would be very different

[jw]

Okio is not an Android library and it's used plenty on the server

[christophsturm]

i really like pure nio. or xnio.

[julienviet]

is Okio able to signal read event on its API ? when I lok at Source I can see the read method but it seems to be a polling API and it does not seem designed to be signaled of channel readability

[jw]

It's not push based, no