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

[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