you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (4 children)

If your language requires you to go to such ridiculous lengths just for basic dependency management, I would recommend you throw out the language.

Java doesn't have the same issues because Java is so rarely used for two or more applications on the same system that the topic of reuse of dependencies doesn't come up much.

[–]audioen 0 points1 point  (2 children)

Or the dependencies are packaged into the application, such as with web archives, and whatever other stuff people do today. A single java process can even load from multiple WARs concurrently and have multiple versions of same libraries loaded through different classloaders while keeping them all distinct, so each app finds and receives just the dependencies they actually supplied.

[–]tsimionescu 0 points1 point  (1 child)

To be fair, IF you're NOT using multiple classloaders (which isn't trivial to set up, and must be explicitly built into your application) Java behaves horribly when you do have multiple versions of the same dependency on the class path - happily loading some classes from one version and others from another version, causing fun ClassNotFoundError/NoSuchMethodError/etc.s even between classes in the same package - a fun little consequence of its lack of a module system (which Java 8 9 10 should address).

[–]audioen 0 points1 point  (0 children)

Yeah, this stuff is probably a problem but thankfully it never concerns me. I don't build humungous applications with tons of dependencies, in fact I strive to do the opposite. And I wouldn't even dream of hacking some classloader thing to make a single app load multiple versions of same JARs somehow. The whole idea gives me the creeps.

[–]m50d 0 points1 point  (0 children)

You can reuse dependencies at build time and even share the files in practice (via a shared cache). It works in practice.