[lmm]

No. Decent packaging systems like used in the Java world have deterministic or mostly-deterministic dependency resolution; semi-decent packaging systems like the ones you mention have lockfiles. Pre-uv Python packaging is uniquely awful.

[acdha]

What do you prefer for lockfiles in the Java world? I’ve been trying to drag a couple of Maven teams into the 2010s after finding that they weren’t.

[lmm]

You don't need them. Maven has deterministic dependency resolution (unless you use version ranges, but don't do that), so you just write your dependencies. (The flipside is you may want to get in the habit of doing something like versions:use-latest-releases as a regular housekeeping task so that you pick up any security updates, but that tends to be less of an issue in Java-land for other reasons)

[acdha]

Why don’t I need them? I can’t make every third-party package do exact version pins and it’d be miserable if I could because then I couldn’t patch a transitive dependency faster than the upstream even if there’s a drop-in patch release which is 100% compatible.

Even if that worked, I’d also want hashes to avoid file modification, although that’s less of a concern for anything on Maven Central where the releases are immutable.

[lmm]

> I can’t make every third-party package do exact version pins

Every third-party package already uses exact version dependencies, you don't need to do anything.

> then I couldn’t patch a transitive dependency faster than the upstream even if there’s a drop-in patch release which is 100% compatible.

You can always override the transitive dependency version if you want to.

> I’d also want hashes to avoid file modification, although that’s less of a concern for anything on Maven Central where the releases are immutable.

It's not just Maven Central, there's a strong norm of releases being immutable everywhere. If you're worried about attacks, there's a plugin you can enable to check the GPG signatures.