Make kotlinx-coroutines-core (with runBlocking in it) available as transitive dependency.

[m-koops]

Fixes issue #570

Due to the code changes runBlocking is needed in every use of Mockito-kotlin, also for projects without coroutines.
That's why Mockito-kotlin should declare 'kotlinx-coroutines-core' as a transitive runtime dependency.

This PR is superseded by PR #575

[TimvdLippe]

Two things:

1. Please add a subproject regression suite based on 6.2.0 regression stubbing broken for non-coroutines project #570 (comment)
2. I agree that we should keep this optional if possible. Can we update the code to handle the case where classes don't exist? We use that pattern in mockito-core as well: https://github.com/mockito/mockito/blob/d16fcfc274d7ca03a2b4bdc22dd7c3ec6dac8690/mockito-core/src/main/java/org/mockito/internal/junit/ExceptionFactory.java#L23

[m-koops]

I'm happy to have another look into this. Problem is that the Kotlin compiler fails to resolve overloads of a function that just differ in taking a regular or a suspend lambda as it's argument. The Kotlin compiler team is working on this. They released a fix as experimental feature. But the fix did not make it into the last release of Kotlin. I hope to find some time later today to find the better fix.

…

On Thu, 15 Jan 2026, 09:01 Tim van der Lippe, ***@***.***> wrote: *TimvdLippe* left a comment (mockito/mockito-kotlin#571) <#571 (comment)> Two things: 1. Please add a subproject regression suite based on #570 (comment) <#570 (comment)> 2. I agree that we should keep this optional if possible. Can we update the code to handle the case where classes don't exist? We use that pattern in mockito-core as well: https://github.com/mockito/mockito/blob/d16fcfc274d7ca03a2b4bdc22dd7c3ec6dac8690/mockito-core/src/main/java/org/mockito/internal/junit/ExceptionFactory.java#L23 — Reply to this email directly, view it on GitHub <#571 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPJG7P7FLBJS2POUNFZQTD4G5CMLAVCNFSM6AAAAACRWW324GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJTGM2DONZYGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[m-koops]

2. I agree that we should keep this optional if possible. Can we update the code to handle the case where classes don't exist? We use that pattern in mockito-core as well: https://github.com/mockito/mockito/blob/d16fcfc274d7ca03a2b4bdc22dd7c3ec6dac8690/mockito-core/src/main/java/org/mockito/internal/junit/ExceptionFactory.java#L23

This have looked in a solution like this myself. But the issue is that the argument of the whenever function is now marked as suspend function/lambda. One can pass either a regular lambda or a suspend function into this function. But once marked suspending, there is no way to unmark it as suspending. And the passed in function therefor can only be invoked in a coroutine scope. Hence runBlocking is needed.

It's a pity that the Kotlin compiler does not yet allow to specify 2 overloads of the whenever function, 1 for regular lambdas, the other for suspend lambdas. Once that option is provided by the compiler it is way easier to support the non-coroutine without the need for a dependency to kotlinx-coroutines-core.

Tomorrow morning I will dive further into the 2 regressions reported. And I will do my best to come with the least intrusive fixes to them.

[m-koops]

Two things:

1. Please add a subproject regression suite based on 6.2.0 regression stubbing broken for non-coroutines project #570 (comment)
2. I agree that we should keep this optional if possible. Can we update the code to handle the case where classes don't exist? We use that pattern in mockito-core as well: https://github.com/mockito/mockito/blob/d16fcfc274d7ca03a2b4bdc22dd7c3ec6dac8690/mockito-core/src/main/java/org/mockito/internal/junit/ExceptionFactory.java#L23

Please see PR #575, that provides a fix without adding the new dependency.
Also this PR introduces a new module that tests stubbing a mock in absence of the kotlinx-coroutines-core library.