Hello, I'm having this stacktracke while I'm tryin...

# koin

[orafaaraujo]

Hello,
I'm having this stacktracke while I'm trying to work with api/impl module

E/AndroidRuntime: FATAL EXCEPTION: main
    Process: ......, PID: 29490
    java.lang.StackOverflowError: stack size 8MB
        at kotlin.reflect.jvm.internal.pcollections.IntTree.get(IntTree.java:93)
        at kotlin.reflect.jvm.internal.pcollections.IntTree.get(IntTree.java:93)
        at kotlin.reflect.jvm.internal.pcollections.IntTreePMap.get(IntTreePMap.java:42)
        at kotlin.reflect.jvm.internal.pcollections.HashPMap.getEntries(HashPMap.java:85)
        at kotlin.reflect.jvm.internal.pcollections.HashPMap.get(HashPMap.java:51)
        at kotlin.reflect.jvm.internal.KClassCacheKt.getOrCreateKotlinClass(kClassCache.kt:32)
        at kotlin.reflect.jvm.internal.ReflectionFactoryImpl.getOrCreateKotlinClass(ReflectionFactoryImpl.java:50)
        at kotlin.jvm.internal.Reflection.getOrCreateKotlinClass(Reflection.java:59)
        at org.koin.android.ext.koin.ModuleExtKt.androidApplication(ModuleExt.kt:54)

[orafaaraujo]

Is there a way that I can debug to know what's happening?

[orafaaraujo]

What I’m trying to do

factory<FeatureA> {
    FeatureAImpl(
        featureB = get(),
    )
}

factory<FeatureB> {
    FeatureBImpl(
        application = androidApplication(),
        featureA = get(),
    )
}

[bastienC]

A cyclic loop no ? FeatA needs FeatB, and FeatB needs FeatA ?

[orafaaraujo]

yep, apparently

is there a way to handle it?

[bastienC]

No idea, seems not a good idea to have cyclic dependencies

[bastienC]

They are coupled, should not

[arnaud.giuliani]

there was a cycle dependency detector in previous 2.1.x, for performance consideration I’v removed it. But worth to consider it again later 🤔

[Nicolas Picon]

It is better to break the cycle, but you can sometime work around it using delayed injection:

factory<FeatureA> {
     FeatureAImpl(
         featureBProvider = { get<FeatureB>() },
     )
 }

factory<FeatureB> {
     FeatureBImpl(
         application = androidApplication(),
         featureAProvider = { get<FeatureA>() },
     )
 }

Both feature implementation must be modified to take a () -> Feature instead of a Feature though

[bastienC]

By “delaying” the injection, how can you be sure you won’t have the same issue again ? ie. FeatA is really fat, FeatB isn’t, you may encounter the issue again no ? (bad timing for example)

[Nicolas Picon]

You cannot be sure, that's why decoupling is better.
This pattern mostly work if the injection is needed to react to some callbacks, like an onClickListener

[bastienC]

Ok, thx for the confirmation

[arnaud.giuliani]

You can even use inject() in the DSL to have a Lazy<T>

[orafaaraujo]

Thank you, mates
I ended up changing my implementation to not have this cycle dependency, I believe it would be safer 😅