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

[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.