Mark Alvaro
12/15/2021, 12:59 AMrunBlocking
, but I doubt that’s a performant or even suggested approach, and it won’t work for JS or common).
As far as working with the service using Kotlin goes, whether in my common, JVM, JS, or whatever source set, I had no issues. The problem I have is consuming the service from Java code of course adds the Continuation argument, which isn’t something I want to impose on consumers of these services. I’ve seen a few threads in this channel about this issue, but I’m still wondering if there is any documentation or examples on how to make consuming the suspend function from Java sources more friendly. I saw mention of transforming to Futures or RxJava Singles or some other equivalent type, which is totally fine, but I’m not sure where to look for examples on how to even achieve that. I also know I can create a JVM-specific implementation that uses runBlocking
, but again I’m pretty sure that should be avoided. Am I correct that using runBlocking
would actually be worse than making the service using a RestEasy blocking client, due to coroutines not wanting to be blocked? Or would the performance be similar to a traditional blocking client, and I’d just be giving up benefits from using coroutines? Any pointers or links to guides would be appreciated!Bruno Medeiros
12/15/2021, 1:59 AMcommonMain
coderunBlocking
is completely fine if you’re designing a blocking API. Maybe you can provide 2 methods in your Java API, one that is a requestAsync
and returns a future and another request
that runs the same thing , but around a runBlocking
Mark Alvaro
12/15/2021, 2:02 AMBruno Medeiros
12/15/2021, 2:21 AMrequestAsync
returning a Promise
on the JS side as well, this should be possible in the jsMain
side of things