koin VS spring-fu

Koin - Dependency injection

In the Kotlin ecosystem, dependency injection (DI) frameworks are essential for managing dependencies, improving modularity, and streamlining application development. Koin has emerged as a popular DI framework for Kotlin developers, especially valued for its simplicity, lightweight nature, and multiplatform support. At the time of writing, Koin 4.0 has been released. Built on Kotlin 2.0, this release introduces a wide range of enhancements and Compose Multiplatform features. As we move into 2025, Koin continues to be an excellent choice, particularly because of its Kotlin-first design, ease of use, and adaptability across platforms.

The Koin framework is now updated to support the latest Kotlin version, now integrating with Google KSP. Koin Annotations 2.0.0-Beta1 to take advantage of Kotlin 2.0.20 and KSP 2.0.20-1.0.25, and target Koin 4.0. This release is based on the stable 1.4.0 version.

Added Koin as Dependencies Injection framework

Koin to manage dependency injection (more explanation about that later)

Let's see how we can use Koin to achieve Dependency Injection (DI) and incorporate a third-party iOS Swift SDK in a KMM project. Koin supports KMM development, making it the ideal choice for KMM projects.

Spring-Fu GitHub Repo

The point isn't that one should reinvent the way that Tomcat is started, but that Spring Boot (by default) is using action at a distance and runtime reflection which have serious downsides if you want to understand what's actually going on because you're a) new to the technology, or b) have to debug some weird edge case.

The alternative is using explicit, reflection-less code - which you can do even with Spring, although it's experimental: https://github.com/spring-projects-experimental/spring-fu

Bean Definition -> Still needed although experimental projects like Spring Fu might remove their need in the future. Technically, there is nothing to stop you from registering beans functionally right now but the verbosity is likely to make that approach less optimal.

Most of these things can be done with higher-order functions too.

I think that if Java had had lambdas earlier, Spring and other such frameworks might look very different. You can see that already, Spring is adding (experimental?) support for more declarative styles of configuration instead of the rather slow and hard-to-debug reflection magic: https://github.com/spring-projects-experimental/spring-fu

> And that is a problem how? Stick to one style.

Switching an API from "a result or nothing" to "a result or an error message" happens all the time, and switching in the other direction is only slightly less frequent. And of course most programs have some APIs where one is appropriate and some where the other is. So consistency is valuable.

> https://github.com/spring-projects-experimental/spring-fu/tr...

Still reflection-based.

> There's nothing magical about it.

It's magical to anyone thinking in the language - it breaks the rules of the language, so you can't reason about what it does.

SpringFu (from Spring team): https://github.com/spring-projects-experimental/spring-fu/tree/main/jafu

It's mentioned in the article, even though the examples are written in Kotlin spring-fu supports a java-based dsl.

It's possible to remove it anyway, provided you accept to use APIs considered experimental. The solution is Spring Fu, with "Fu" standing for functional. It's available in two flavors, one for Java and one for Kotlin, respectively named JaFu and KoFu.

There is already a very close collaboration between Kotlin and Spring teams. I think leveraging more multiplatform capabilities and more DSL à la KoFu from https://github.com/spring-projects-experimental/spring-fu could increase Koltin usage on server side long term.