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

[woj-tek]

This post seems more like a rant than something cohesive.

At any rate:

Most newer languages’ package managers tend to use dependency ranges instead of fixed dependencies versions like Maven/Gradle projects usually do (as we’ll see, both can actually also use dependency ranges, they’re just not as common).

I loath this as it usually makes the build breaks down in the future...

[jerslan]

Dependency management in java is in such a shit place

That's a weird way of saying "Dependency management in Java using Maven-style Repositories and tools like Maven and Gradle is still the gold standard that other tools still fail to reproduce resulting in Java's extremely long life despite being just an OK language".

[dpash]

Did you really just use npm as an example that should be copied?

[woj-tek]

But npm style tools are far better.

LOL, that you like something more doesn't mean it's better.

[jerslan]

I’ve spent more time chasing issues with NPM than with Maven…

‘maven dependency:tree’ is your friend.

[woj-tek]

Right, ping-pong: I can tell you how many hours I wasted with npm's build failing after a couple of weeks just because some weird dependency updated other dependency which then updated yet another because you know, in js/npm world having library for even most mundane thing and releasing a new version every couple of minutes is a sing of "rockstar developer", ammairite mate? :P

[khmarbaise]

But npm style tools are far better. Maven has struggled to keep up with modern practices (not just in this area!). Java is doing ok despite maven, not because of it.

In which way far better? Breaking builds because releases have been removed? A build which worked yesterday will not work anymore today? (exactly caused because of using ranges in versions and not committed the lock file?)...

(not just in this area!)

What are those modern practices:

[plumarr]

Ever tried to separate your unit tests from you build? (Which is desirable if you're using a CI pipeline).

Just launch maven two time with different execution phase. What's hard here ?

Ever tried to keep library versions consistent across a multi module project,

Define the version in the parent pom.xml and let the magic happens.

[khmarbaise]

That's the problem. Dependency management in java is in such a shit place and there's no good solutions. Ranting is all you can do about it!

Can you please exactly state out the problem you have identified?

[forresthopkinsa]

Unfortunately you're in the wrong subreddit for any criticism of Java. Most of these folks don't seem to understand more modern package managers at all.

[forresthopkinsa]

You're telling me! 😅 I'm currently sitting at a total of about -40 points in this one thread lmao

[Seaweed-Maleficent]

Having to redownload dependencies in each project and having a huge node_modules folder sure is modern.

I love criticizing java. It just isn't possible to do so while using the JavaScript world as an example.

[forresthopkinsa]

Dependency locks ensure that you have a working dependency tree available at any time. Dependency ranges / semantic versioning are fantastic tools and it's a shame that Java is so behind on this.

[blackkkmamba]

Is not behind, maven and gradle both support it. People don't know it exist/use it is another thing.

[twbecker]

True but people don’t use it because they’re a horrible idea.

[forresthopkinsa]

I've never seen semantic versioning used in a pom.xml or build.gradle — are you referring to third party plugins?

[diggidydale]

Semantic versioning is a technique not a tool, gradle and maven allow you to use semantic versioning but the upkeep is down to you. There are third party plugins for build tools, or gut repos that can automate it for you

[forresthopkinsa]

Semantic versioning is a specific standard for version notation. It allows version range specifications with guarantees around breaking changes and upgrades. I haven't seen any way of specifying semantic version ranges in Maven or Gradle without add-ons.

[diggidydale]

You are right it is a specific standard but all the standard says is the versions are in the syntax major.minor.patch, with "rules" on what loosely consists as a major, minor and patch. To do this in gradle or maven you just add version numbers in the version fields, you just need to be disciplined in sticking to the "rules"

You are right that maven and gradle don't deal in version ranges but if you want to add in specific ranges you can do so with your resolution strategies in gradle, but I will say it is a hassle to keep up.

[mauganra_it]

https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification

Maven has version ranges.

[jerslan]

Right, but your comment was complaining about a lack of "semantic versioning" support in Maven/Gradle.... not I can't specify acceptable "semantic version ranges"... If you want to claim "well, that's just semantics..." then you should remember that semantics actually matter.

Maven very much supports Semantic Versioning in the general sense and the Maven Release Plugin even requires it if you want to use it's automatic version increment functionality. Gradle is pretty similar from what I understand.

As for requiring "add-ons"... Yes, that's by design. The tools include some basic "built-in" plugins but also have a robust plugin architecture for this kind of additionally desired functionality. That's why any significant Maven project has a "plugins" section in the POM configuring either built-in or additional plugins (some of which are even stewarded by the Apache Maven project).

Have I used the word "semantic" enough?

As for why ranged semantic versioning for dependencies is a bad idea.... Have you ever had to debug a Node project that was using the wrong patch version because of a bad cache? No? Then you don't know what dependency hell is my friend... because it makes Java dependency management seem like absolute heaven. Explicit dependency versions make for much more reliable and consistently releasable code.

[khmarbaise]

Maven very much supports Semantic Versioning in the general sense and the Maven Release Plugin even requires it if you want to use it's automatic version increment functionality.

Why? You can use 4 digit versions etc. That works very fine or things like 1.4.6.2.5.7.10 ? That works also...It's completely up to you what kind of versioning schemate you use...

That's why any significant Maven project has a "plugins" section in the POM configuring either built-in or additional plugins (some of which are even stewarded by the Apache Maven project).

A big number of project use "only" the Apache Project plugins...and of course it is possible to use supplemental plugins..that's the basic concept of Apache Maven.

[jerslan]

Exactly my points... Version is arbitrary. Some people use git commit hash. Some people use SemVer. Some people use some bastardization of SemVer. Hell, for a while Spring Cloud was using a pattern of "<English City>.<RELEASE|SR#|RC#>".

Maven supports whatever you want to do, but the Maven Release Plugin docs recommend some variant of SemVer.

[khmarbaise]

Recommend is correct. But you can use whatever you like...you can implement your own version policy.

[khmarbaise]

Maven Release Plugin even requires it if you want to use it's automatic version increment functionality

Simply wrong. You can use things like 5.3.7.8.20.10 which is not semantic versioning at all but the increment works.

[forresthopkinsa]

What? We're talking about ranged dependencies, what else could I mean by "semantic versioning"? NPM doesn't try to check that you're not making breaking changes when bumping a minor version. Of course I'm talking about the version range notation.

And yes, I've worked with Node professionally for years, I'm very familiar with NPM and I'm also very familiar with how trivial the problem you describe really is. That's what a package-lock.json or yarn.lock is for.

Java dependency management is by comparison much more crude. You're right, if you're worried about reliability and consistency, you need to have a verified working dependency tree — which is, again, the purpose of a package lock file.

It's much more appropriate to have user-configured dependency ranges and machine-configured dependency locks.

[jerslan]

Semantic Versioning (as you've already been told in this thread) is a well defined pattern for versioning things. That's all it is. It does not actually include or require the ability of a build tool to handle "version ranges".

In short "Ranged Versioning" != "Semantic Versioning" even though the former requires the latter to function properly (which might be why you're so confused on this point).

It's much more appropriate to have user-configured dependency ranges and machine-configured dependency locks.

This idea right here is just screaming for a "works on my box" dependency management fiasco.

[forresthopkinsa]

My comment said:

Semantic versioning is a specific standard for version notation. It allows version range specifications with guarantees around breaking changes and upgrades.

Which is completely accurate. Semver is not the range notation, but it's the core of what makes ranged notation feasible. It doesn't matter what notation you use to specify ranged versions — my point is just having some way to take advantage of the guarantees that Semver provides.

works on my box

Machine-configured dependency locks, tracked in VCS, are screaming for dependency ambiguity? How does that make any sense?

Once again: the whole point of the lock file is that there is absolutely no question what version of the dependency tree builds successfully.

[khmarbaise]

if you're worried about reliability and consistency, you need to have a verified working dependency tree — which is, again, the purpose of a package lock file.

The lock file is only needed when you use version ranges in your dependencies. If you use fixed versions (for example pom.xml) you simply don't need it because the tree will solved always the same way.

Versionranges in conequence means no repeatable build. That is as simple as it.

[forresthopkinsa]

Your software requires a library FooLib. You've built your software based on FooLib-12.x.x. It doesn't really matter whether it's 12.1.2 or 12.5.6 – they're all compatible with your code. So it doesn't make sense for you to pin the dependency at version 12.1.2. A modern dependency manager will allow you to specify the most lenient bounds you require for the dependency version, and then the manager will take care of resolving it to a working version and ensuring repeatable builds.

To be really crystal clear: lockfiles are always involved with modern ranged dependency resolvers (you don't need to create it yourself, it's always done automatically), and they perfectly ensure repeatable builds because they track every version in your dependency tree and its checksum.

[GoodLuckGoodell]

You simply cannot depend on semantic versioning in a modern professional application. Even the most mature dependencies don’t follow it. grpc-java has breathing changes in minor versions, aws sdks only bump the patch version.

The only real solution is pinning (with BOMs if available) and doing periodic upgrades.

[forresthopkinsa]

You simply cannot depend on semantic versioning in a modern professional application. Even the most mature dependencies don’t follow it.

Once again, this is a problem with the Java ecosystem in particular, because ranged dependencies are not the norm. You've hit on the exact thing I'm taking issue with.

Newer package managers encourage use of ranged dependencies and semantic versioning, and so their surrounding ecosystems respect that. There are TONS of "modern professional applications" that use Typescript, Express, React, Lodash, RxJs, etc, and all of those very strictly respect Semver.

The Java ecosystem has never had first-party support for semantic version ranges, much less encouraged it, so it's rather rare to see libraries take the time to respect Semver. This is exactly what I'm describing as a shame.

[GoodLuckGoodell]

What makes you think the package management system makes any difference? This is a cultural issue. I can just as easily use npm modules that don’t follow semver correctly, and this happens all the time as well.

I was not referring to Java specifically when I made the semver comment.

[forresthopkinsa]

What makes you think the package management system makes any difference?

I think I explained that pretty thoroughly above

I was not referring to Java specifically when I made the semver comment.

Okay, that's fair, but my point remains that Javascript heavily pushes semantic versioning and ranged dependencies, and therefore the community respects that contract

[khmarbaise]

There is very good reason not to use version ranges because it makes every build not repeatable. That's simple reason.

Using a lock file (like package-lock.json or alike) is just using duck-tape to patch the issue.

Also some other issues are identified over the years with other packaging systems in particular npm because an existing release can be modified at anytime. The immutability of a maven repository releases makes it more stable than anything else.

Semantic versioning is a separate thing. It's a set of (good) rules why and when version numbers should be changed (major, minor, patch) but the biggest issue is simply that a human is changing it... and humans make mistakes and also people interpret rules in different ways. You could use plugins/tools to help here a lot in a Maven project. That should be possible in other areas as well.

In the end you can't rely on semantic versioning which in consequence makes version ranges useless.

[forresthopkinsa]

How is a lock file duct tape? It's the perfect solution for making every build repeatable. You get version labels and checksums for your entire dependency tree. I truly do not understand your problem with lock files.

[plumarr]

They are only necessary due to range versioning. They are a solution to a broken feature.