This is a real world problem, and I say that as someone who has been doing Java and Scala for many years. When you are exploring code trying to figure out how it works and what it does, it's easy to follow the chain of what method is this, where is it implemented, where is this symbol imported from, etc. Subclassing introduces some ambiguity in method parameter types, but at least you can get some information from the documentation of the interface or abstract class, and you can find usages of the method and see what concrete types are passed in different places. Where it really breaks down is dependency injection and annotations. When you hit these, it's no longer "command-click" or "google for Javadoc" to find out what's going on; it's a minor research project. With annotations, if you can't find the information you need in the documentation, you will have to search the source code of the framework and study the code that processes the annotation before you can even locate the code you're looking for[0].
You might be thinking this is pretty awful, but hey, software is complicated, you have to understand the code you're working on —- fine. It's reasonable to put this amount of effort into the code you are actually working on. But when you're working on service A and have a question about service B, it's nice to be able to pop over to service B's source code and find the answer without investing a lot of time understanding the technologies underlying it.
This is why "enterprise" Java programmers end up obsessed with anointing "best practice" frameworks. Me relying on a big magical framework for everything I do is only problematic because some other people don't use it. Solution: let's establish my framework as the "de facto standard," and then nobody can complain that it's ridiculous overkill for simple applications. Let's make proficiency with my preferred framework part of the definition of being a professional Java developer, and then nobody can complain about how time-consuming it is to get up to speed with it.
The alternative is to use libraries instead of frameworks, use as little magic as possible, and work in a language that is powerful enough that you can write straightforward code and still say everything you need to say in a reasonable amount of space.
Consider the simple, ubiquitous case of writing a method to implement a POST endpoint in a database-backed CRUD web service. Suppose you need to authorize the request according to some business logic, deserialize the entity body, validate the body according to some business rules, get a database connection, construct a query, run the query, process the query results into a response object, set the status code and headers for the HTTP response, and serialize the response body. Why shouldn't all of this functionality be discoverable in the code via chains of method calls from the method that implements the endpoint? With a concise language and a well-organized codebase, this is entirely possible. Readers of your code can see: here's where to dig in if I want to see how the request is deserialized, here's where to dig in if I want to see how the database query is constructed. If your code becomes exhaustingly verbose when you express it in this straightforward way, then your language is failing you.
As a fan of Scala, I have to admit that Scala introduces a similar difficulty with implicits (and the horrible practice of using wildcard imports to import entire menageries of implicit methods and values, which is epidemic in FP-style Scala.) Implicits are indisputably widely abused, but at least IDEs can show you how implicits are resolved at compile time, and in your own code, you can make implicits reasonably readable without IDE support by declaring them in an enclosing scope with a good name.
[0] I'll make an exception for one style of annotation: annotations that point you directly to the relevant code, like @ExceptionMapper(MyExceptionMapper.class). This is almost always all the information I need, the only exception being if the person who wrote MyExceptionMapper misunderstood some subtlety in how it gets wired in via ExceptionMapper.