best practice in java is to mark classes as final (effective java book)

final classes cannot be mocked by Mockito

if only I was good at programming and writing higher level integration or acceptance tests to circumvent this

Mockito sounds like something that was shot a while ago.

That's why you need DI, mock should just be the name for a kind of interface implementation that only supports one usage pattern and blows up if you do anything else with it.

I've never agreed with that "advice" and found it to almost always be ineffective and more headache inducing

best practice in java is to use something else.

@lorentz yeah but you don‘t even need DI for that. Just use interfaces.

@Lensflare Interfaces have basically two uses; one's to add user-defined candidates to heterogenous collections, the other is inversion of control. When I say DI, I don't mean a DI container that uses reflection or whatnot to automate the process, but plainly the practice of parameterizing a piece of code on an interface even when the choice of implementation is assumed to be universal just so you can change the context of the code more easily.

@Lensflare I'll die on this hill; DI containers don't contribute anything to 99.9% of projects. Just take a factory callback or an instance as a constructor parameter. It's marginally more code, and the ability to manually overrule the global configuration for a specific place of use without affecting other instances of the same class is well worth it.

DI containers were born in an era before every language had lambda functions with good type system support and lexical scoping.

@lorentz agree 100% on the DI containers.
I‘ve been trying to explain this to my coworkers for years when I was a C# dev.
They wouldn‘t listen.

Btw, C# has a huge ecosystem with a lot of different DI container libs, despite it having lambdas for ages. So I don‘t think it’s necessarily related to that.