1) In my experience, code bases that have lots of single-implementation interfaces have generally been really bad. Over-engineered, pointless layers, etc. I’m sure this isn’t the case for all projects that use them (especially yours, of course , it’s just my experience.

2) Stepping back, in some ways I think the distinction between classes and interfaces is no longer useful and instead becoming a hindrance. AFAIK the perf for method dispatch is the same, so why not have all classes have interfaces? Except you don’t declare them, it just happens.

E.g. “class Foo” gets a “Foo” interface and “Foo$” implementation. Whenever you do “new Foo”, the compiler knows to do “new Foo$” but the variable type stays “Foo”. Now you can mock/whatever Foo to your heart’s content.

If, for some reason, Foo really shouldn’t get an interface, perhaps you could add a java.lang.NoImplicitInterface annotation, which would tell the compiler to behave in the current/standard way (not that such a drastic change in compiler behavior would ever make it into Java itself).

A little while ago I was feeling out an architecture that used single-impl interfaces, and so built an annotation processor that does basically this:

https://github.com/stephenh/interfacegen

So you write Foo, add @GenInterface, and it will automatically create/update as-you-save an IFoo.

I’m not saying it’s perfect (and annotation processors in general can be finicky–especially this one, IIRC), but if you really want single-impl interfaces, it seems like a good compromise compared to maintaining both by hand.