Updated_the_above_snippet_for_a_bit_more_context_o...

# coroutines

[Herko]

Updated_the_above_snippet_for_a_bit_more_context_on_my_library_mixing_issue.kt

Updated_the_above_snippet_for_a_bit_more_context_on_my_library_mixing_issue.kt

[gildor]

I see now what you mean.
Problem of your case, that this Java API doesn't support asyncronous supplier, it have to be syncronous.

[gildor]

You have 2 options:
1. Refactor Java code to support asyncronous supplier (so java should subscribe itself on supplier result)
2. If it's not possible, the only what you can do is use runBlocking, to block thread to get value syncronously

[Herko]

I was afraid that might be the case. Is runBlocking safe to use? https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/run-blocking.html

[gildor]

Also, I'm not sure that it will work for you real case, but you can first request for value from suspend function and when it will be ready subscribe on get and pass value that you already received asyncronously
But it, of course, changes semantics of code, it's not so lazy as could be with asyncronous supplier support

[gildor]

What do you mean safe to use? Depends on your case, such call will block thread until your suspend function return value, safe it or not depends on your code

[Herko]

The way the description is written just makes it sound like you shouldn’t be using it for production like activities.

[Herko]

I think option 1 might be more viable.

[gildor]

Yes, usually you shouldn't use it, but it's a bridge that allows convert asyncronous coroutine to syncronous code

[Herko]

Thanks again for all the help.

[gildor]

Yes, if you have access to Java code and can change it, I would just convert supplier to some CompletableFeature or other asynchronous primitive that can be used on java side and than you can easily use coroutines (see for example future coroutines builder, that crwates ConpletableFuture from suspend block)