[Scarbutt]

I can see how DI will be overkill for a wedding website and Javalin/jdbi/sqlite is more than enough but for most business applications written in Java you really wish you had started with DI. Any DI libs you recommend for working with Javalin?

[tipsee]

Hard disagree on needing a DI library, manual DI is great.

[Scarbutt]

Disagree on using a lib? cause I guess doing manual DI is still DI.

[tipsee]

Yes, disagree on needing a library. The way your comment was worded made it seem to me like you were saying all serious Java applications need a DI library, I'm sorry if I misunderstood you. I prefer doing my ID manually, so no recommendation :)

[mkingston]

Could you be more explicit, perhaps with an example? Do you simply mean you prefer function/constructor parameters over DI?

[erpellan]

Calling a constructor is DI. ‘new’ is the only DI framework required.

Benefits:

Unbelievably fast startup time

No magic

No annotations, XML or YAML required

No classpath scanning related security vulnerabilities

Conpletely deterministic

In no other language is ‘calling a constructor’ considered so complicated a framework is required.

Try it!

[therealdrag0]

It took me a hot moment to adjust after leaving classic spring Java land to a Scala shop that doesn’t use DI framework, but now I love it. I agree with what you said.

It does help to keep services small so the manual DI arg passing doesn’t get too spread out and boilerplate-y. But I have worked on a dozen services here and don’t miss an automatic DI framework.

[KronisLV]

> Calling a constructor is DI. ‘new’ is the only DI framework required.

This feels like the sane thing to do, but sadly for historical reasons this won't work with many (if not the most) Java frameworks out there, or even certain options in the .NET ecosystem.

When you get non-trivial frameworks that are deeply entrenched in having DI and using it internally for a bunch of stuff, you'll find yourself out of options, e.g. if you use Spring/Spring Boot.

And in many places something like Spring Boot might be considered an "industry standard" and you might get looked at funny if you suggested using another framework, even more so if they have their own configuration/plugin/utility solutions for it already built within the org.

Personally, however, I rather enjoy alternative takes on how web frameworks could look and even something like Dropwizard/Vert.X/Quarkus have nice quality of life aspects to them.

In a sense, it's nice that the industry is moving towards smaller service based architectures, where you might spin up a new service with whatever tech fits the problem that you're trying to solve, as opposed to being locked into adding code on top of some bloated monolith (though that comes with certain tradeoffs and drawbacks, in regards to complexity and maintenance).

[coverj]

I have a few questions about this approach, cards on the table I mainly deal in C# where DI (through the framework) is the default. How do you manage the initialization of all of the dependencies? Do you need some sort of "root" where everything is initialized and passed in? That was all I could come up with while keeping it testable and that doesn't sound maintainable once you build up the number of dependencies.

[thiht]

When I switched from Java to Go and started doing DI like this, I was amazed at how simple and efficient DI could be. I was taught DI with Spring and never fully grasped why and how it worked. With Go it just clicked and to this day I still have no idea why DI libs are so complicated. If I ever come back to Java, I’ll make sure to do DI manually.

[vips7L]

Any DI lib would probably work, it depends on your preferences and use cases though.

I'm personally a fan of Weld since its the reference implementation of the CDI spec.

https://weld.cdi-spec.org/

A friend of mine built an MVC library around Javalin that uses Dagger as the DI container: https://github.com/jehugaleahsa/javalin-mvc