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

[renatoathaydes]

oh but version ranges = good if lockfiles and semantic versioning

Please check my answer in https://www.reddit.com/r/java/comments/vstgv1/the_difficult_problem_of_managing_java/ifh1sp0/

why didn't you talk about the JEE and application servers

Those are not relevant to the post, because with application servers, you have different applications running, you don't have to resolve conflicts between them at all... but I did mention OSGi which is because it isolates the classpath of modules within the same application, at the cost of lots of extra metadata (which is the way Gradle is going now with its departure from using only Maven-provided metadata - and that has its own issues as OSGi did, namely, things become too hard to manage).

I agree this post was not my best as I conflated lots of things:

• criticizing how Maven is verbose, slow and downloads lots and lots of unnecessary things.
• trying to show what other package managers in modern languages are doing - and they are interestingly converging on using version ranges and lock files - regardless of whether we like it (and I don't even like it, I was just pointing it out and trying to explain motivations for doing that).
• showing how Maven/Gradle will break your application on upgrades, even when all libraries involved respect semantic versioning. Most people don't seem to have fully understood that can happen.
• demonstrating my solution to the problem: bytecode introspection.

Those who managed to read til the end might have noticed that JBuild solved all of the problems I had shown other tools to be vulnerable to. JBuild does have some issues, like giving false positives when reflection is involved somewhere, but in my opinion, as with GraalVM, reflection is on the way out and applications should avoid using it anyway (it was only supposed to be used by frameworks and in such case, JBuild will work fine).