I don't fully understand the issue with threads. I see that the problem might exist when e.g. you call coroutine1->coroutine2 and you have synchronized between them coroutine1->synchronized->coroutine2 in that case it is true the call to coroutine2 might end up on a different thread and the lock won't be unlocked. That issue might exist when one coroutine calls another or coroutine calls another async api which might be adjusted to it (e.g. CompletableFuture, Reactor, RxJava, etc).
But I don't understand your example with Guava cache. You won't be able to pass suspend function to guava hence the thread which returns to Guava will be the same. In order to call coroutines from non-coroutines you will need to have boundary call (runBlocking, GlobalScope.async, etc) which will protect you from thread flip. I cannot even image situation where I could get this issue (except when you call synchronized from coroutines (which you should probably never do)).
The other issues - yes debugging is quite annoying thing which you could overcome by having multiple breakpoints (I would describe it as medium level inconvenience). Also it is not really issue of the coroutines as concept or implementation, it is a one in Kotlin Idea Plugin debugging capabilities (which from my layman perspective shouldn't be very difficult to fix - just to have a hidden breakpoint at the next line). Passing down context isn't an issue anymore. We pass tenant related info using coroutine context.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't fully understand the issue with threads. I see that the problem might exist when e.g. you call coroutine1->coroutine2 and you have synchronized between them coroutine1->synchronized->coroutine2 in that case it is true the call to coroutine2 might end up on a different thread and the lock won't be unlocked. That issue might exist when one coroutine calls another or coroutine calls another async api which might be adjusted to it (e.g. CompletableFuture, Reactor, RxJava, etc).
But I don't understand your example with Guava cache. You won't be able to pass suspend function to guava hence the thread which returns to Guava will be the same. In order to call coroutines from non-coroutines you will need to have boundary call (runBlocking, GlobalScope.async, etc) which will protect you from thread flip. I cannot even image situation where I could get this issue (except when you call synchronized from coroutines (which you should probably never do)).
The other issues - yes debugging is quite annoying thing which you could overcome by having multiple breakpoints (I would describe it as medium level inconvenience). Also it is not really issue of the coroutines as concept or implementation, it is a one in Kotlin Idea Plugin debugging capabilities (which from my layman perspective shouldn't be very difficult to fix - just to have a hidden breakpoint at the next line). Passing down context isn't an issue anymore. We pass tenant related info using coroutine context.