<@UE0E6UWAJ> Most DI takes place at object instant...

# tornadofx

[carlw]

@alex Most DI takes place at object instantiation time. When you instantiate an object with dependencies, those dependencies are instantiated (and so on). This is called wiring up an app in Spring and Guice parlance. This means forgoing the new operator and using the container in the entry point for your program.

There's also the option of delaying the dependency injection. This can be done by interacting with the container as the program is running. You might delay injection because of performance via lazy loading. You might also do this to break cycles whereby two objects reference each other. One object can use the normal means of DI where as the other object (up to you which is which) must call though the container at a later date.

As a user, this should all be taken care of behind the scenes and your program starts with each component able to execute in the proper context. For something like an EJB, this means with all the datasources and JMS queue connections to do its work. On a UI, this might mean a shared EventBus. So, besides a few annotations (-at-Inject) and a little interaction with the container (getBean(), injector.get()), you shouldn't have to do any clean up or worry about byte code generation.

[alex]

Why EventBus is related to DI? Do you mean that DI must wait EventBus initialization?

[alex]

It's not that I'm worrying about codegen, I'm trying to trace the whole flow to understand how does it work under the hood. I'm trying to use DI from group up, but all tutorials/articles are never covering these parts for some reason.

[alex]

I think I've got most of the parts correctly on my end, I'll look closer to wiring up process and read related DI documentation for frameworks. Thanks!

[carlw]

I would study Google Guice. It's a 670kb JAR that is pretty versatile. PicoContainer is another good one to look at. Spring is most popular, but there's a lot of extra stuff in core

[alex]

It seems like there is no real elegant Kotlin way around DI as I see it. lateinit is ugly, at the same time delegation looks more like service locator and might fail at runtime. The only real option is construction injection, but it is limited in some cases. Duh.
Well, I guess it must be a language feature to begin with, to implement it in one consistent way.