4 ms·
> Basically, a single approach that would solve this, irrespective of the language, would be isolating dependency trees of every library from each other Doesn'
by zokier 4y ago
> Basically, a single approach that would solve this, irrespective of the language, would be isolating dependency trees of every library from each other
Doesn't solve the problem completely because it is normal that applications need libraries to interoperate; consider case where application is passing objects between two libraries that both use types from a third library.
- badpun 4y agoThen your app would explicitly be doing the impendance mismatch resolution (converting objects from one version of library to the other) when doing the library calls.
- CrimsonRain 4y agowhich someone would have to code in as that's not automatically possible all the time.
- jayd16 4y agoYou're pretty much screwed in that case but that's kind of by design and the entire point of versioning, isn't it?
- layer8 4y agoA major problem is that Maven (and friends) doesn’t distinguish between API dependencies (the API of a library using types from the API of another library) and implementation dependencies (a library depending on another library as an implementation detail). If that distinction were made consistently, implementation dependencies could indeed be separated into a dedicated classloader for each library, and you’d only have to worry about API dependencies, which would go a long way. The Java 9 Modules architecture would have been an opportunity to introduce something like that, but alas they didn’t.
- brabel 4y agoOSGi allowed you to specify in excruciating detail what dependencies you had, whether API (i.e you wanted to re-export types from another library) or not, and much more. Unfortunately, it became far, far more complex than just implementing a simple module system, so as most things from the era (early 2000's) it became a huge, complex beast no one wanted to touch anymore.
- clhodapp 4y agoI believe that separating interface from implementation doesn't really solve the problem, it just shrinks it. E.g. what if you depend on two libraries that re-export classes from different versions of a third library? I think that if you truly want to solve the problem, you need to extend the definition of the fully qualified classname to include the notion of a breaking version reference. Kind of like what folks now sometimes do the hard way by encoding it into the package name. This would make it possible to directly address the two different versions from the same calling source file.
- layer8 4y agoI agree, but I believe the “shrinkage” would already reduce the problem substantially, and maybe more importantly, would make developers more careful about what they include as interface dependencies instead of as just implementation dependencies.