Platform compatibility & Genericity

Kodein-DI 7.22.0 is built upon and compatible with Kotlin 2.0.0.

Also, it requires at least JDK 11, for JVM projects.

Kodein-DI is compatible with all platforms that the Kotlin language compiles to: JVM & compatible (Android), Javascript and all the Kotlin/Native targets.

Here is a table containing the version compatibility:

Kodein Kotlin 7.22.0

Compose 1.6.10

1.9.21

7.21.2

Compose 1.6.0-alpha01

1.9.21

7.21.1

Compose 1.5.10-dev-wasm03

1.9.21

7.21.0

Compose 1.5.10-dev-wasm02

1.9.20

7.20.0

Compose 1.3.1

1.8.10

7.19.0

Compose 1.3.1

1.8.10

7.18.0

Compose 1.3.0-rc2

1.8.0

7.17.1

Compose 1.3.0-rc2

1.8.0

7.16.0

Compose 1.2.0

1.7.20

7.15.1

Compose 1.2.0

1.7.20

7.15.0

NOT COMPATIBLE

1.7.20

7.15.0-kotlin-1.7.20-RC

NOT COMPATIBLE

1.7.20

7.14.0

1.2.0-alpha01-dev745

1.7.10

7.13.1

1.2.0-alpha01-dev745

1.7.0

7.10.0

1.0.1-rc2

1.6.10

7.7.0

1.0.0-alpha1

1.5.30

7.6.0

1.0.0-beta08

1.5.21

7.5.1

1.0.0-beta07

1.4.32

7.5.0

Since 7.0.0, a new type system has been designed and included to Kodein-DI. Thus, it appears to the developer that there is no more obvious differences between platforms, you no longer have to choose between erased or generic dependencies. Starting from 7.0.0, Kodein-DI is using the generic version of the type system, meaning you should be able to bind generics easily for Kotlin/Multiplatform projects. So, whatever platform you are targeting, bind<List<String>>() and bind<List<Int>>() will represent two different bindings.
Similarly, di.instance<List<String>>() and di.instance<List<Int>>() will yield two different list.

Since 7.0, Kodein-DI can use generic for non JVM platforms, thus it is now the default implementation. However you still can force the use of erased with the generic and erased function forms!

The JVM case

However, you should be aware that under the hood, this new type system uses the new function typeOf() from Kotlin, for every platforms, except for the JVM that still have it’s own generic implementation. Meaning that the JVM counterpart of the type system makes a heavy use of reflection, so it’s less optimized.

Yes, #perfmatters. However, the humble opinion of the author is that:

  • There is a balance to be found between performance, readability, security and debuggability.

  • Optimisation is important in critical path, not everywhere.

  • Kodein-DI is already pretty optimized ;)

  • In the vast majority of cases, using the erased version will result in no significant performance change to your application, as IoC happens once and is not a performance pitfall!

Therefore, please make sure that, using the erased version is right for your use case, before blindly using it ;). Do profile your code!

Even if by default Kodein-DI uses a generic type system, you still can use the erased one manually.