Hi, does any one knows a good dependency container...

# announcements

[Antanas A.]

Hi, does any one knows a good dependency container to use in Kotlin for backend projects? Good means: work without any configuration and extra plumbing code in trivial cases. E.g. val di = Container.scanAllProject(); di.get(SomeService::class) would create and return a singleton of class "SomeService" with autowiring/resolving constructor injected dependencies automatically.

[ribesg]

I use Koin everywhere I can use Koin (JVM & Android)

[Antanas A.]

but for Koin there is a need to specify each class which will be created?

[ribesg]

Of course, what else do you want to do?

[streetsofboston]

Kodein is another DI framework. If I'm not mistaken, it supports multi-platform Kotlin

[spand]

His question implies auto discovery

[ribesg]

Does that exist?

[Czar]

Spring, you still need annotations though. There is no magic 🙂

[spand]

Well, you could use ie. https://github.com/classgraph/classgraph to find all subclasses of an interface and register them in your DI framework assuming it allows that on runtime.

[tseisel]

Just noticed that Koin uses neither annotation processing nor reflection ... what does it use then ? DSL configuration at runtime ?

[Antanas A.]

Yes, I'm thinking about using classgraph and then somehow call e.g. Koin or Kodein and register all found classes, but then It will need to register also all classes (dependencies) which appears on constructor

[Antanas A.]

and on their constructors also

[Antanas A.]

I've just found https://github.com/davidwhitney/Kotlinject

[Antanas A.]

which seems is what I'm searching for, but using jitpack it not publishing any classes in .jar https://jitpack.io/#davidwhitney/kotlinject/52dbace6b7

[spand]

Maybe you can use classgraph to find all classes which have a constructor with @Inject annotation (if that is what Koin etc. uses)

[Antanas A.]

Koin seems is designed with reified inline functions in mind

[Antanas A.]

so I don't know how to use their API in runtime

[Antanas A.]

Looks like currently there is only spring container

[tddmonkey]

Have you considered just not using a DI container?

[Antanas A.]

yes, it's best approach and we're using just object with by lazy properties, but with a smaller project

[tddmonkey]

It scales fine to larger projects too

[Antanas A.]

in current project there is a need to have some type of "auto discover" of datasources commands mixins without explicit registration

[Stephan Schroeder]

declaring dependencies in koin feels close to Spring's JavaConfig:

val depModule = module(createOnStart = true) {
single<CaseClient> { RESTCaseClient(get()) }
single<TaskClient> { RESTTaskClient(get(), get()) }
...
}

[Stephan Schroeder]

so not very much auto discovery going on here

[sitepodmatt]

We use Koin on a server-side project but Im due to rip it out. Koin seems to be a good fit for Android where you dont have full control over how your app is insitated but outside of that it's horrid imo.

[Antanas A.]

I'm currently testing Kotlinject and it seems best of all, it's port from .NET Ninject

If someone also want to try it you can use jitpack:
https://jitpack.io/#antanas-arvasevicius/Kotlinject/3e06747737

because original repository has only misconfigured maven and is not usable with jitpack.

[Czar]

IFoo -> Foo naming convention

🤬

[Antanas A.]

yes.. see sharp 😃

[Antanas A.]

managed to initialize magic container:

[Antanas A.]

private val container = Container().apply {
    registrations.scan
        .fromClasspathWhere({ true }) {
            it.bindClassesAndInterfaces(
                condition = null,
                lifecycle = Lifecycle.Singleton
            )
        }
}

[Antanas A.]

usage: val datasource = container.resolve(UserDataSource::class)

[Czar]

tripple backticks for multi-line snippets

[Czar]

one
two
three

[Antanas A.]

ty

[Joe]

fwiw, guice does this kind of 'just in time' binding by default if it can. recommend kotlin-guice for doing injector.Instance<SomeService>() instead of having to do a ::class.java call.

[Antanas A.]

how can I be forgotten about guice..

[Antanas A.]

thanks @Joe I'll investigate if it fits our needs

[Antanas A.]

I'd thought that guice always need to define everything explicit

[Antanas A.]

I generally dislike annotation based configurations which guice suggests e.g. @Inject @Named("SMSComms")

[Joe]

yeah we mostly just @Inject primary constructors and use modules to specify anything more that needs it, with a few exceptions where we need @Named to qualify things