> In Java, for instance, there are methods < classes < packages. Once there are dozens of packages and thousands of classes, a project becomes hard to navigate and understand, especially when code isn't well-written with hacks disregarding modularizations. Using microservices reduces scope and prohibits some of these no-gos.

At that point you step up to using multiple maven modules. Which can give much the same development experience as microservices, but without the extra network boundary.

Yeah, that's one way to go, and also supports separate versioning and release cycles of different subsystems.

However, since all code is compiled into one large application there are other problems arising.

One I've seen often is sloppy dependency management: A explicitly depends on B, B on C. Now, a dev working in A starts using classes from C without declaring the dependency. Everything works because C is still included through B, but as soon as B gets removed, things start to break. There is mvn dependency:analyze to discover such issues, but it's not 100% exact, and people need to actively use it.

I think such a system built into and enforced by a language would be another quantum leap.

It's very normal for methods in B to return types from C in that scenario though. And if you do remove the dependency on B, you get the error at compile time. So I don't see this as a major problem (it's maybe a problem if something's implicitly activated by reflection, but I see the reflection as the bigger problem there)

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.