99% of the time I see DI used in Java it is solely to enable mocked dependencies in unit testing rather than injecting different production implementations depending on environmental differences or something like that.
I have had Code Reviews where "This is all good, but you should use Guice to mock X" where X is the one time I might have a package-private test only constructor with a NullObject for the one dependency I need to mock out in a commit and Guice is not currently used in the package at all.
Personally I think DI has reached cargo cult status in Javaland.
Dynamic languages like Python do not have this issue as you can mock any method runtime for the duration of test. This can done via "monkey patching". It is unclean, but the development cost of having a framework to do just this is a tad high.
The only downside is that if you parallel test you need to run them in separate processes (which you usually want to do.any case).
I have had Code Reviews where "This is all good, but you should use Guice to mock X" where X is the one time I might have a package-private test only constructor with a NullObject for the one dependency I need to mock out in a commit and Guice is not currently used in the package at all.
Personally I think DI has reached cargo cult status in Javaland.