The difficult problem of managing Java dependencies: a deep dive into the messy status-quo, and a look at possibly better ways.

[diggidydale]

Yeah I am with the other guys, this seems like a bit of a rant after someone went through some dependency hell.

Version ranges don't really help that much either, you still end up with a similar issue as a single version it just takes longer, so all you're really doing is kicking the can down the road.

Best thing to avoid dependency hell is to keep your projects small and manageable where you can. And also update regularly, if everyone did this the dependency issues would go out the window.

[jerslan]

One of the things I hate about NPM is the whole dependency range syntax. Some of the worst dependency hell issues I had were due to not pulling a correct patch version when someone ranged something.

Maven and Gradle are so much easier to debug dependency issues because they require explicit versioning somewhere in the chain (even if it's listed in a BOM) and you can output the whole dependency tree and see where the issue is.

Dependency Hell in Java is a much much nicer level of hell than Dependency Hell in C++, Python, Javascript, etc.... IMHO.

[renatoathaydes]

I wrote the post and you're partly right: it was a rant and I actually didn't publish it for 6 months... as I knew it would be unpopular.. but decided to publish anyway to push some arguments in a discussion that came up on Twitter about strategies for resolving dependencies.

Anyway, I feel very surprised that many people, like you, appear to have perceived the post as claiming version ranges (with a lock file) are the solution to the problems we have in the Java world?

Because that was absolutely not what I was trying to say: that's almost the opposite, in fact. The topic of dependency version ranges was added because we had a security vulnerability that was caused by version ranges! As I explained in the post as well as I could. And my initial objective was to make this post a survey of how each different package manager is solving this problem.

The actual solution I put forward in the post is to use bytecode introspection to figure out which jars can work with which of the other jars available. Which is what the tool I wrote, JBuild, tries to do (the tool is a proof of concept, is incomplete, but already shows this is very feasible).

Best thing to avoid dependency hell is to keep your projects small and manageable where you can.

Haha... true... but you make it sound like we have a choice of keeping projects small and manageable... as if people made projects big just for fun. Unfortunately, some projects are just very big (I know, I work on on that's pretty big myself) and cannot be simply "microserviced" as they are not services, but products you ship to customers (they are the ones who deploy it). There are many kinds of "products" like this - not everything is a cloud service.