Skip to content

Spring Boot 3.5 dependency management downgrades Kotlin and coroutines and the app fails at startup #33

Open

Description

@rennf93

Reproduced with the published com.guard-core:spring-boot-guard:1.1.0 in two throwaway Java 17 apps: Maven importing the spring-boot-dependencies 3.5.6 BOM, and Gradle with Spring Boot plugin 3.5.14 plus io.spring.dependency-management. In both, the BOM manages kotlin.version 1.9.25, kotlin-coroutines 1.8.1 and kotlin-serialization 1.6.3 and overrides the versions the adapter and engine were built with (Kotlin 2.4.21, coroutines 1.11.0, serialization 1.11.0).

The result is a startup failure: NoSuchMethodError: kotlinx.coroutines.BuildersKt.runBlockingK$default while creating guardMiddleware. Coroutines 1.11.0 added runBlockingK, which the Kotlin 2.4 compiled classes call, in this adapter and in the guard-core facade. Overriding only coroutines to 1.11.0 gets past startup but every request returns 500 with ClassNotFoundException: kotlin.coroutines.jvm.internal.SpillingKt, because coroutines 1.11.0 needs a Kotlin 2.x stdlib. Overriding both kotlin.version to 2.4.21 and the coroutines version to 1.11.0 works (normal 200, rate limited 429, attack payload 400, security headers present).

The facade compiled against old coroutines is an engine change and out of scope here. What the adapter can do is document the required alignment for Spring Boot 3.5 apps, which I will do in the README and the installation docs.

Activity

  1. rennf93 commented on Oct 17, 2026

    @rennf93
    MemberAuthor

    I reproduced this with the published 1.1.0 in a Maven app (spring-boot-dependencies 3.5.6) and a Gradle app (Boot plugin 3.5.14 with dependency-management). Both resolve kotlin-stdlib 1.9.25, coroutines 1.8.1 and serialization 1.6.3, and both fail at startup with NoSuchMethodError: kotlinx.coroutines.BuildersKt.runBlockingK$default, because coroutines 1.11.0 added runBlockingK and the adapter and the guard-core facade call it. The workaround is to align kotlin.version to 2.4.21 and the coroutines version to 1.11.0, which I documented in #34. The root cause is in the engine, so the fix comes with the 4.5.0 engine release; this issue stays open until then.

  2. self-assigned this
    on Oct 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions