When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Then, the right version needs to be determined by following removed intermediate modules. It would just be cleaner and more reliable if the original dev had done this when writing the code in question.

But yeah, at least it fails on compile time already.

> When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in.

Just go to search.maven.org and do a full class name search, no?

The problem is that this doesn't work for modules not published there, i.e. if you have a large in-house code base split into many maven modules.

IDEs can open classes by name, wherever they are on the classpath. I'd normally have all projects open in any case even on quite large codebases - it's very practical with modern hardware.

Indeed, but it takes some time to get there in case of dozens or hundreds of modules in different git repos (again, depending on the size of your ecosystem).

I just don't see how this is a problem. For any class on your classpath, ctrl-shift-t or whatever will go to it. If removing a dependency lead to missing that class, you can probably just open it, and you can certainly revert the removal and then just open it. Or do a classname search on your internal maven repository.