Has there been any updates on the inability of mod...
# koin
w
Has there been any updates on the inability of modules/libraries built with differing versions of Koin to be consumed together due to method signature mismatches? Context: https://github.com/InsertKoinIO/koin/issues/1369
a
do you know what API it crashes? Between 3.1 & 3.2 there have been some API instability but I can help if needed
The thing is it will pull the library in latest version for your project then. Your app with Koin 3.2 is then running with it
w
Totally get that, but these are also minor versions so it's a bit confusing how there could be API compatibility issues. In the same thread another person mentions the same issue across 3.2 -> 3.3 upgrade so I am concerned this is an ongoing problem. I will grab a fresh crash log quickly so I can paste here in case it is different
We have seen some issues with our own internal API's where even when adding default arguments, this alters the method signature in the compiled code, causing no such method errors and we've had to use
@JvmOverloads
even when calling from Kotlin for compiled + published libraries
a
what APIs is it?
w
No specific API that I can tell. I'm working on getting a fresh stack trace for you
👍 1
Caused by: java.lang.ClassNotFoundException: Didn't find class "org.koin.dsl.ModuleKt"
Copy code
fun getCommonsModule() =
    module {
}
Copy code
FATAL EXCEPTION: main
    Process: <http://com.demo.app|com.demo.app>, PID: 4743
    java.lang.NoClassDefFoundError: Failed resolution of: Lorg/koin/dsl/ModuleKt;
        at com.demo.app.koin.CommonsModuleKt.getCommonsModule(CommonsModule.kt:8)
        // SNIP
Caused by: java.lang.ClassNotFoundException: Didn't find class "org.koin.dsl.ModuleKt" on path: DexPathList[[zip file "/data/app/~~Omqwg6UZcfOR1GqNDwlxcg==/com.demo.app-ENEVG6KsBr6WPEZVYlvRhA==/base.apk"],nativeLibraryDirectories=[/data/app/~~Omqwg6UZcfOR1GqNDwlxcg==/com.demo.app-ENEVG6KsBr6WPEZVYlvRhA==/lib/arm64, /data/app/~~Omqwg6UZcfOR1GqNDwlxcg==/com.demo.app-ENEVG6KsBr6WPEZVYlvRhA==/base.apk!/lib/arm64-v8a, /system/lib64, /system_ext/lib64]]
        at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:259)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:379)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
        at com.demo.app.koin.CommonsModuleKt.getCommonsModule(CommonsModule.kt:8)
As far as I can tell, it's unable to find the
module
function
In this case here: App Version: 3.5.6 Library Version: 3.1.6 The error here is in the library
Which makes sense since the version used at runtime would be 3.5.6
I've tried this in the reverse order previously, and it causes the same problem
a
I don't remember such diff in API. Is it coming from calling
module { }
?
w
Yep the line that is called in the crash log,
CommonsModule.kt:8
a
can you update one of your app?
w
Sorry I’m unsure what you mean, one of my app?
a
sorry. The library is working on Koin 3.1.6 ... ok I see. Nobody have access to try fix the lib?
(jsut in case)
w
I think the issue for me is: How often is this going to keep happening? Is this a one-time problem? I am currently trying to utilize this in a fairly high profile application, we have around 30 internally published modules to maven. This means that to upgrade off of version 3.1.6, I have to upgrade and publish every single internal library. And just this last week, we need to upgrade to a new version of dependency. This new version has adopted Koin and is using version 3.5.6. So what this means is now in order to utilize this new dependency version we are forced to upgrade our application as well as our all internal modules 😕
1
a
3.5 reintroduced best practices about checking API and ensuring compat over versions. If it can help
3.5.6 is the last stable and has been check with lots of feedback
👍 1
e
I'm also running into this issue, I distribute an SDK library and one of the consumers was unable to use it due to different Koin versions in the library vs implementing application.
a
what versions are you using?
e
3.1.3
and
3.4.0
. I will be upgrading to
3.5.6
soon, but if this remains an issue we're probably going to have to discontinue use.
a
@Evan there is known breakings from 3.1 to 3.3. If you can upgrade to 3.5, it's a good point. Let me know if we can help