3 ms·

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 larg

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.

lmm 10y ago
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)
- blauditore 10y ago
  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.
  - lmm 10y ago
    > 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?
    - blauditore 10y ago
      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.
      - lmm 10y ago
        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.
        blauditore 10y ago
        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).
        lmm 10y ago
        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.

lmm 10y ago

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)

blauditore 10y ago
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.
- lmm 10y ago
  > 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?
  - blauditore 10y ago
    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.
    - lmm 10y ago
      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.
      - blauditore 10y ago
        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).
        lmm 10y ago
        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.