Personal experience. We have some java code from 15-17 yrs back. About the time “design patterns” and all the other “pattern” stuff was big in everyones mind. It’s a mess of abstraction for simple tasks. Couple all that with the fact that class instantiating is possible via reflection and at this point people maintaining it have kinda given up. It works - don’t touch it.
This isn’t an indictment of Java. Just resume driven design.
Programmers are highly trained like to see the world as if everything can be cast the same way. While that IS a good way to see a large variety of software problems, when you isolate down to a companies' use cases, it quickly goes away in the pragmatic sense. It then becomes something the company is paying for because they chose Java and Java developers like that sort of thing.
I feel like - opinion, not based in fact, I've never worked on any codebase >1M LOC - the only way you can keep a codebase like that maintainable is by very strict code style and architecture rules - e.g. no functional programming, no feature X, no feature Y, strict code style rules, strict architecture rules, etc.