[hocuspocus]

I haven't really touched Java in a while but I don't get why you'd want a lightweight DI container.

You can just build your object graph and pass dependencies manually if you want a lightweight approach, no? That's just the way people do it in most languages.

[WatchDog]

I think there are a lot of Java developers, that have just never worked without a DI framework, and just don't have a grasp on just how simple it can be to write code without one.

[eximius]

As someone who hated Java, used it for a few years, and now occasionally misses it...

I only miss DI. I miss being able to say "this system depends on these external things" and having a consistent, convenient way of sharing/swapping/testing those components and dependencies.

The solution in other languages? Unstructured globals, deep argument passing, or monkey patching with mocks?!

Yea, I can write simpler code without DI... By ignoring a bunch of stuff.

[WatchDog]

You can do DI without a framework.

If you write classes with final fields, with a constrcutor that takes the class' dependencies,and don't use static fields to hold mutable data.

You are doing DI. Just call `new` yourself, instead of having the framework do it for you.

[stickfigure]

When you have lots of things-that-create-things-that-create-things, this gets tedious really fast. DI frameworks exist because they result in a lot less code that does nothing but pass dependences along.

This reminds me of SQL/ORM debate. "Just use SQL!" Sure, until you get tired of typing the same SQL over and over and realize you can cut out most of that crap by adding an ORM.

[yencabulator]

The trick is to not encourage that many things-that-create-things-that-create-things. That's a uniquely Java problem.

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

[stickfigure]

If you take the single responsibility principle even as much as half-seriously, the problem domain more or less decides which things will create which things. If your software platform can't support that, you get spaghetti mess when programmers inevitably build workarounds.

[kaba0]

Why? With such a well-known framework like Spring, you will get the benefit of any Spring-developer knowing instantly the conventions (which is not true with your in-house conventions where I will have to hunt down where does this class come from, oh this ugly abstraction which is buggy as well), less code is less opportunity to introduce bugs, less thing to maintain. Annotations are basically just a declarative DSL for a significant chunk of your code base.

I really don’t see any cons, other than a slight learning curve (and yeah sure, “developers” that just bash keys will have trouble with understanding what does an annotation do and blindly copy-pasting them can be dangerous but they will also fk-up regular code as well..)

[heurisko]

> Sure, until you get tired of typing the same SQL over and over and realize you can cut out most of that crap by adding an ORM.

And adding an ORM isn't either/or. You can still use native SQL when necessary.

[EdwardDiego]

Yep, but if you have to change 5 constructors to get a new dependency to where it needs to be, calling `new` yourself starts to suck.

[eximius]

> Just call `new` yourself, instead of having the framework do it for you.

But at that point, why would I want to?

There are reasons I wouldn't want to, but there is no inherent value, to me, in manually calling new.

[jeffffff]

by calling new yourself you get a sane stack trace when something is misconfigured. that alone is worth the tiny additional amount of code in my book.

[kaba0]

How is that worthy? You pretty much only have to look at the topmost exception, or at worst the causing one. Whether it has 100 lines after or 3 doesn’t matter, not the slightest.

[jcelerier]

But how do you handle configuration then ? At some point you want a user-facing UI where the available features (which are generally classes) are listed and the user can choose the feature, say which log backend is enabled, without having to change code - that's the whole point of it. (And the most tedious code to write by hand - a complete waste of time)

[pgwhalen]

> But how do you handle configuration then ?

In the main method, then you can pass the configured values wherever you need to when new-ing classes.

> At some point you want a user-facing UI where the available features (which are generally classes) are listed and the user can choose the feature, say which log backend is enabled, without having to change code - that's the whole point of it. (And the most tedious code to write by hand - a complete waste of time)

I consider DI a valuable pattern, but I've never experienced anything close to this need.

[kaba0]

What happens with proxied classes? My ClassWithTransactions is actually a subclass of the written one auto-generated by Spring. I can’t inject a new instance of that manually.

And you may say that you don’t need Aspect Oriented programming, but the usual handling of transactions in many other languages without some meta-programming is.. to not handle transactions. Putting a single annotation over a method is imo a very elegant way to handle this needed functionality.

[jcelerier]

> I consider DI a valuable pattern, but I've never experienced anything close to this need.

Literally every non-toy software I had to develop in my life required that lol

[xmodem]

My company chose exactly this design for several of our microservices. It is now almost universally considered to have been a mistake.

[otterley]

Why? What happened?

[xmodem]

It very quickly becomes an unmaintainable mess once the service grows past a certain size.

[kaba0]

Which is the standard way to do DI in Spring as well? It will be just called by reflection instead.

But frankly, how will you call that new if it depends on a class which is a singleton, another which has some more complicated scope so it may or may not have to be reused? DI is not only about calling new..

[danidiaz]

Another useful feature of Spring is aspect-oriented-programming (like when we manage transactions boundaries with @Transactional).

Spring takes care of that, but doing it manually (and without dynamic proxies) would add to the verbosity.

[guelo]

Is what you're thinking of equivalent to deep argument passing? I've seen it done where you pass around a global Factory object that can provide dependencies. It's basically rudimentary DIY DI.

[WatchDog]

It's really very simple, no you don't need to pass around a factory object.

You just have a class/classes that construct/wire all of your singleton objects and passes the required dependencies into their respective constructors as necessary.

Here is a contrived example of what the wiring code might look like for a web app that uses a database.

    public static void main(String[] args) {
        MyConfig config = readConfigFile();
        DatabaseConnection dbConn = new DatabaseConnection(config.dbHost(), config.dbPort());
        UserDao userDao = new UserDao(dbConn);
        UserController userController = new UserController(userDao);
        List<Controller> controllers = List.of(userController);
        WebServer webServer = new WebServer(config.listenPort(), controllers);
        webServer.runAndBlock();
    }

[erik_seaberg]

How is it better to make a dev write out that plumbing and others reread it? I’m made of meat, so I want to automate everything we safely can.

[guelo]

Unless WebServer is the only class that needs dependencies you're either going to have to pass those dependecies repeatedly from class to class or you're going to have a global factory that provides the dependencies to everybody.

[Too]

Yep. Once you get too many arguments what you do is usually to create some kind of Context class that bundles all of them and just pass that on everywhere.

[ragnese]

I'd say that the only one of your listed solutions-in-other-languages that is actually a valid solution is deep argument passing.

And I fail to see why it's a problem. If your FooService depends on a BarService, which depends on a BazService, and BazService needs a database connection, then that means your FooService really does also depend on a database connection. Hiding that information, to me, seems like a mistake. Can you articulate why one would prefer not to have FooService explicitly require that database connection, or am I inadvertently arguing against a straw man? If so, please correct me, because I'm asking sincerely.

Of all the time I spend thinking about my code and writing code, I truly can't say that adding a dependency and having the compiler complain until I fix a bunch of constructors has really caused me that much grief. And I'm not going to pretend that it has never been the case that I've had to fix 20 constructors.

[eximius]

Ultimately, I think thisnis going to come down to preference.

I would prefer not to have to fix 20 constructors.

It's tedious and time consuming. The intermediate classes that _do technically depend on FooService because BarService does_ - the intermediate classes don't care! It clutters the code everywhere else for minimal benefit.

Manually, you see all your dependencies just shy of main where the binary initializes them all and starts passing things down. In DI, you have a module file somewhere with them all.

[ragnese]

Definitely a preference thing- no doubt.

But thank you for responding anyway.

(As a clarification, in case it's needed: I obviously didn't LOVE it when I had to update 20 ctors after changing a somewhat fundamental "service" to need a new dep. My point was that, even as painful as that was, it wasn't that bad and it's usually much less bad than that.)

I guess the (philosophical) difference comes to this statement:

> The intermediate classes that _do technically depend on FooService because BarService does_ - the intermediate classes don't care!

I can definitely understand what you're saying there, but it's interesting to me that I don't see it that way. I think I'm just less pragmatic and more... "academic" (?) about how I read and understand my own code. If X depends on Y and Y depends on Z, I'm comfortable with X explicitly depending on Z because I imagine "inlining" Y's functionality in X. Either that or you turn Y into an interface and then X only depends on IY. But, my brain just likes the explicit continuity I guess.

Cheers!

[int_19h]

The solution in other languages is to use a DI framework written for them. Which one doesn't have any? In .NET, the basic DI interface (imports/exports etc) is even part the standard library as System.Composition.

[EdwardDiego]

You say that, and I usually agree, I mean, constructor args are the simplest form of DI.

But then, working in a complex codebase, I introduce a new dependency that is instantiated early in the tree, used two disparate classes rather deep in the tree, suddenly I'm changing 10 different constructors just to get the new dependency where it needs to be.

The tree of constructors is where DI shines as an alternative.

[yashap]

That REALLY depends on the size of your codebase. When it’s small, no need for a DI framework. But when it grows large, it becomes quite a pain, and a DI framework is nice, eliminates a bunch of boilerplate with every code change.

[jillesvangurp]

A good DI framework just saves you from having to spell out all the glue code; or at least minimize that. DIY dependency injection is indeed a useful skill to have with other languages. Unfortunately, it's not what a lot of people do with other languages because they simply don't know that it would help them.

Particularly in the javascript world there seem to be a lot of people struggling to write good, testable code mainly because they make the rookie mistake of not separating their glue code from their business logic. Basically they have bits of code that initialize whatever and they need to put it somewhere and it ends up in the wrong place and before you know it, it becomes impossible to isolate any functionality such that you can actually test it easily without booting up the entire application. Add global variables to the mix and you have basically an untestable mess.

I still use Spring (but very selectively). They've added multiple styles of doing DI over the years, which is confusing. The latest incarnation of that uses neither reflection nor annotations and is very similar to the type of code you'd write manually if you had the time to clean it up and make it nice to use. Another benefit is that it enables native compilation, which with the recent release of spring-native is now a thing people do. Spring is large and confusing but the DI part is actually pretty easy to use. If you've used Koin or Dagger on Android, it's similar to how that works.

[hocuspocus]

I've used Spring DI. I understand the argument for it, when building bigger applications, though it invariably brings its own complexity too.

What you say about compile-time DI to allow native images makes me feel like we've almost come full circle. I'm still not convinced you need automatic DI at all for smaller services.

[stickfigure]

Sure, and eventually you end up rebuilding an [ad hoc, informally-specified, bug-ridden, slow] DI container because:

* Static references become a tangled mess, and you start wanting some structure around that.

* You have to answer "how does ABC component get access to DEF?" for increasingly difficult combinations of ABC and DEF.

Excepting Spring, pretty much all Java DI containers are lightweight.

[benhoyt]

Why do "static references become a tangled mess"? In my (limited) experience with runtime DI libraries (albeit in Go) they turn clear, IDE- and debugging-friendly code where the compiler tells you at compile time if you got it wrong ... into a hard-to-debug magical soup.

With static, using-the-language dependency injection, isn't the question of "how does ABC component get access to DEF?" answerable with the normal IDE/language tooling, rather than some magical library's way of doing it? You can just find the calls to a constructor and look at the arguments.

My experience is based on my bad experience with runtime DI libraries, and is definitely biased against them, but I must be missing something here.

[stickfigure]

There are lots of reasons why static references are undesirable, but some of the more serious are:

* Static dependencies make testing harder, no question about it. This is mediated in dynamic languages like Ruby by mocking statics. While you can actually do this in Java with Powermock, avoiding mocks entirely is even better. If you can't use a real object, use a fake that implements the relevant interface.

* Statics mean singleton, and that invariant often changes as a product matures. It's very easy to go from "the database" to "a database", and when you have 500 places getting "the database" it's very hard to make that evolution.

* Statics make it very hard to maintain module boundaries, because every static is its own exported interface. In a long-running project, binding tends to get tighter and tighter as every module reaches out for the statics of other modules.

Sure, folks can write bad code with DI systems too. And I'm no fan of Spring - not because of the DI, which is fine, but because of the need to wrap everything else in the universe and now you have to understand both how the underlying thing works and the way Spring changes it. But something like Guice or Dagger is just the right amount of glue to hold a system together, without getting in your way.

[benhoyt]

Just a note: I overloaded (excuse the pun) the word "static": I didn't mean the "static" keyword, but "statically compiled/typed". So it doesn't mean singletons, just that you pass dependencies as explicit arguments to constructors and functions.

[stickfigure]

I do not understand what distinction you're making. In the world of DI, you still have typed constructors and factory methods. It's not like Guice turns Java into Ruby. The only difference is that you don't have to chain together constructor boilerplate - in fact, the static types determine the injections.

Do you object to passing interfaces vs concrete types? That is a wholly orthogonal concern; you make the choice to extract interfaces with or without DI.

Maybe you have an example?

[geodel]

> but I must be missing something here.

As a Java developer for all my career here is my take. In Java world there is this cultish cottage industry of "frameworks" for all sorts of work. Most Java developers are not expected to write plain code with JDK standard + some external libraries. Creating an object via "new Obj()" might cause programing universe to collapse so DI framework is must for enterprise Java developers.

If I were to tell at work that Go has inbuilt http server where we could implement a few handlers and have a basic service running. They would not be shocked that a http listener could be this simple but rather ask "Does Go bundles "weblogic/websphere/tomcat/netty" server with it or else how can it work? Same with testing, no understanding on how, what is to be tested but everything about "JUNIT/Mockito/Mockster/SpringUnit" or whatever.

There is no requirement for understanding basic concepts for testing, client/server, dependency, error management etc. So even basic functionalities are understood in terms of a branded framework. This is their main frame of reference.

[mslate]

Just to echo this is similar to my experience. Java development culture that I have known in the work place is extremely coddled by their frameworks.

It is hard for them to open the terminal and execute their application JAR from the command line--only ever from the IDE. Oh wait--they need Tomcat/Apache & a few hours of dealing with classpath issues.

[bzzzt]

That's just a problem with developers who do Java as their 'nine to five' job and don't have any interest or passion to really find out how stuff works. I've met a lot of those people and there's no reason they can't contribute if the project is set up to accommodate it.

On the other hand there are the enthousiasts (like you I presume) who like tinkering and using the language to the fullest. Any successful project needs at least a few of these people, but they can also go overboard by building a lot of custom functionality where any standard library could have been used.

While I'm also an advocate for increasing knowledge for the systems you're working with it's no 'sin' to use some libraries. For instance: for your HTTP server example, it's quite easy to just listen on a socket and respond to a request. But you want parallelism, so you need a thread pool. And queues, configuration and error handling. That will escalate quickly so why not pick whatever Java servlet implementation which has most of the complexity and - more important - is already production tested so it won't fall over when you deploy it live. And then there's stuff like OpenID connect or SOAP (yes, still exists) where you can 'plug in' an implementation on some servers so you can get work done instead of worrying about getting all the implementation details right for some complex protocol.

[geodel]

> but they can also go overboard by building a lot of custom functionality where any standard library could have been used.

Well I am kind of recommending using standard libraries. And servlet implementation I am using embedded tomcat as I mentioned in other comment. What I am not doing is generating gratuitous scaffolding of dozen packages and innumerable classes because that is the "best practice".

[otterley]

I’m a little confused. Why is creating a new Java object via “new” a sin? After all, it’s right there in Chapter 1 of any Java tutorial.

[geodel]

Just to clarify it is not my opinion. It is the groupthink of enterprise Java programing where reading Java tutorial itself would be obscure thing. Everything has to be looked from "framework" perspective. Framework says 'new' is bad so it is bad, dependency has to be constructor/setter injected by DI container so that's how it has to be.

[kaba0]

No framework says `new` is bad. Feel free to grep for new in any framework application. But if one uses DI, than do use it for classes that ought to be injected. But inside methods of course one can and do use `new` many times over.

[overgard]

In my experience most DI just interferes with being able to use the IDE to track down instantiations. Ive worked on these projects that basically have these fancy runtime things to answer questions that could be answered by the IDE if it werent so obscured. I remember one project we had a fancy thing to generate a graphviz graph, and it was like neat, but we could just use find all references if we just called new.

The dumb thing is most of the time only one type is ever injected. Its all hypothetical flexibility which has a cost but no benefit

[geodel]

> I remember one project we had a fancy thing to generate a graphviz graph, and it was like neat, but we could just use find all references if we just called new.

Ha. Calling `new` would either be an absolute enterprise Java sin or an obscure aracana. Some people are quite proud of the fact of converting compile time errors to runtime exceptions. Because you know "best practices" and all.

[kaba0]

It definitely has a benefit at scale. I’m not sure what application were you developing, but the amount of time a single instance was changed into an interface because the client wanted the n+234th little change in this special star constellation.. with DI you don’t have to write any more code, you can even use different implementations per environment (@Profile), so this is not accidental complexity in most cases. Sure, if you need a 100 lines web server that prints hello world it is an overkill, but the correct tool for the job..

[singron]

"static" in java DI can refer to setting global variables with singleton instances. E.g. java logging libraries usually do this so that you don't have to DI everywhere you want to log. In Go, some packages do this like flag and log. In Rails, this is so common that it replaces DI entirely, but I usually didn't feel like rails suffered from it.

I think what you are referring to is just manually doing DI. I.e. you defined constructors that accept dependencies and then call them all in a main function. I think this is tolerable if your codebase is structured for it. In typical java codebases, it gets ugly really fast. IMO this is caused by a general proliferation in the number of classes (due to class-per-file among other reasons), as well as a tendency to never use "static" DI. As an extreme example, if you needed to inject a logging dependency, then almost all code would need to be part of the DI graph. In a typical web backend, you might DI the sql connection pool. This causes basically all code to need DI since it either uses sql or has a transitive dependency that uses sql. IMO injecting the connection pool is not useful since it's not useful to write tests where you inject anything other than a real sql connection.

[benhoyt]

Ah, that explains the confusion. Yeah, I didn't mean static as in the "static" keyword in Java / C++, but as in specified in the statically-typed code. Defining constructors that accept dependencies -- exactly. Ah yeah, I can see how Java exacerbates things here with the one-class-per-file rule -- ugh.

Go doesn't require one class (well, type or struct in Go) per file, and has much more flexibility in how you build packages as a result. I think it's a good thing that dependencies like the logger and the database are passed around explicitly: I've learned the hard way that "explicit is better than implicit" even when it means a bit more boilerplate.

[jupp0r]

Dependency injection does not have to be dynamic, it can totally be done at compile time. Boost DI is an example: https://boost-ext.github.io/di/

[vips7L]

There’s plenty of Java frameworks that are compile time too. Quarkus, Avaje Inject, etc all do their wiring at compile time.

[throwaway1492]

This, it’s really exhausting to read this never ending wheel reinvention. Sure any one can use simpler non-spring frameworks, and other “non standard” frameworks and libraries for 1/10 or 1/100 of the functionality, and get 10-100x the bugs and much less or zero support. But we need netty! And then when you add thread pools, jdbc, logging, etc? Yep you’ve reimplemented spring. Just use spring, spend the time to learn it and reap the rewards.

[wtetzner]

As someone who dealt with a ton of Spring in the recent past, I completely disagree.

First of all, thread pools are part of the standard library. Spring adds little to no value on top of it.

Second, reinventing some of that stuff is absolutely worthwhile, because Spring's library design/implementation is not very good.

Finally, when I had the opportunity to start a new Java project, I opted to not use Spring. I finally had a server that started up fast, took less code than a Spring project, was easily navigable in an IDE, and whose code was generally easier to follow. It was also easier to write tests for.

One thing I learned is that people seem to underestimate just how thin Spring's abstractions are over stuff in the library, servlets, etc. Most of what Spring does is wrap things in a bean interface so they can be used with DI (which is something I’ve never found any value in).

[geodel]

Well you are missing one of the great feature of Spring framework: Converting compile time errors in to runtime exceptions.

Jokes apart you are absolutely right about non-spring based services. I did same using plain Java + embedded tomcat for some services. No cargo-cult like endless decorative packages and classes. Exactly same result as you observed. Less code, fast to start and vastly improved error management.

[specialist]

> Converting compile time errors in to runtime exceptions.

Heh. Stealing this. Short, sharp, undeniable.

I usually say something snarky like "Spring is an exception obfuscation framework" or "...flow of control obfuscation framework".

[geodel]

> Heh. Stealing this...

Yeah, please popularize it. In my case I am unable to make management see reason. If more devs become vocal about it make it a trend, it will be a good thing to happen.

[RedShift1]

Same here. I've gotten rid of all that stuff, it's just layers and layers of indirection that contribute nothing.

One rule that has also helped me a lot to keep my code clean and make it easier to debug is to fail as much as possible in the constructor. So when you call new MyThing(), you will either get a usable object or it'll throw an exception. Further method calls are expected to work. Of course this is not doable for everything, but it sure helps keeping the methods clean and not have them throw various exceptions.

[jicea]

Could you share your Spring/Spring Boot alternatives? Are they Java based? I'm doing backend stuff with Spring Boot and I would like to test alternatives. Spring boot is not that difficult to work with, but I would like to test a "simpler" solution.

[ludovicianul]

I would recommend Quakus, Microprofile, Micronaut.,

[mmcdermott]

I've had similar experiences. A few years ago, I wrote a small service in plain Java, no frameworks as part of a quick change to improve performance. It worked and we all moved on. Later it was converted to Spring Boot and it slowed way down.

[xxs]

> But we need netty! And then when you add thread pools, jdbc, logging, et

java.util.concurrent has threadpools and pretty damn decent at that; jdbc is a part of very standard jdk, logging is part of java.util.logging. Why do you need netty (which is not a part of spring either way)?

In over 23y of working with Java, I have never needed spring.

[throwaway894345]

Agreed. Stuff like this feels like magic for magic’s sake, and as someone who has had to operate services that use these DI frameworks, they are a big pain.

[kaba0]

How about learning about the tools you use beforehand?

You don’t sit into a car without any knowledge about it and blame it that it is magical.

[throwaway894345]

I read all of the documentation for the service that I operate--per my other comment (https://news.ycombinator.com/item?id=29973282), often times things aren't well-documented and it's crucial to be able to look at the source code to figure out what something does (e.g., how is a configuration parameter used? what are its valid permutations?); however, when the source code is obscured by gratuitous complexity then it imposes a high cost on the user and in the case of DI frameworks, that gratuitous complexity comes with no discernible benefit (a car offers me something of value to justify its learning curve). Personally I'm of the opinion that a person shouldn't have to be a seasoned Java developer to use so many tools that are implemented in Java (or any other language, for that matter).

[throwaway1492]

What does “operate” mean in this context? I’m generally curious why one should consider this comment to be anything other than low effort flame bait?

[throwaway894345]

Operate means “run the service”. If you need to configure things which aren’t well documented, it’s nice to be able to look at the code, but the DI frameworks obscure the code path. This is pretty straightforward; no idea why this would seem like flame bait—I didn’t even realize this was something people held deep emotional attachments to.

[lmm]

Plumbing the construction of your object graph manually does not have a particularly high cost/benefit - most of your services are singletons that depend on each other, and it's already clear enough which ones depend on which others without repeating yourself. A very basic "here's a bag of classes that depend on each other, wire them all together and then let me pull out the instances by type" is often worthwhile for avoiding all that boilerplate, even if it does break the rules of the language a little. Something like Picocontainer or even Guice is pretty good IME.

[dep_b]

Not using Java but generally in OO languages I ended up passing forward dependencies in grouped and themed classes like LoginDependencies, InboxDependencies etcetera. Everything under an Interface so you just mock whatever you need. Never ran into serious issues.

Of course logging might be static but “true” dependencies like networking classes never are.

[EdwardDiego]

I want lightweight, and compile time. But I'll take compile time only if need be.

In terms of lightweight, I have never needed to use the @Alternative binding [0]. Nearly all of my needs are met by being able to define "this is a singleton, this is a dependency that you should always inject a new instance of, and this is a property."

But it's surprisingly hard to find DI that limits itself like that. The DI in Micronaut and Quarkus are probably the closest to my ideal. Compile time, and only implement a subset of CDI etc.

[0]: https://netbeans.apache.org/kb/docs/javaee/cdi-validate.html

[waynesonfire]

here is the talk, good stuff, Dead-Simple Dependency Injection

https://www.youtube.com/watch?v=ZasXwtTRkio

[eximius]

Replacing DI with Free Monads is not what I'd call simple. It's not even possible in a type safe way in most(?) languages.