https://kotlinlang.org logo
#coroutines
Title
# coroutines
j

jw

09/06/2017, 12:48 PM
sad to see it's just nio's APIs
o

orangy

09/06/2017, 1:16 PM
Can you propose something different/better/interesting?
j

jw

09/06/2017, 1:47 PM
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.
o

orangy

09/06/2017, 1:59 PM
Is there a design doc or something justifying the difference? Not opposing, just curious
j

jw

09/06/2017, 3:47 PM
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.
o

orangy

09/06/2017, 4:05 PM
That would be awesome!
k

kenkyee

09/06/2017, 8:24 PM
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...
o

orangy

09/06/2017, 8:26 PM
As if the whole world is only Android 🙂 I believe requirements for IO on a server would be very different
j

jw

09/06/2017, 8:32 PM
Okio is not an Android library and it's used plenty on the server
c

christophsturm

09/07/2017, 8:19 AM
i really like pure nio. or xnio.
j

julienviet

09/07/2017, 3:49 PM
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
j

jw

09/07/2017, 3:49 PM
It's not push based, no
2 Views