Once more onto my regular soapbox.

Plenty of language communities want to avoid various mistakes (or at least, perceived mistakes, some people consider these features even if Java has retroactively moved away from them) that the Java ecosystem made over the years - verbosity/ceremony^(1), repeating yourself with types everywhere^(2), calling everything a bean, that weird XML phase it went through in high school, generic type erasure, Spring and it's massive runtime DI complexity^(3), and of course design patterns to mitigate language shortcomings, etc. etc.

But they all really screwed the pooch by not following Java's dependency management approach:

(With the caveat that NPM and PyPi (probably more, I'm just commenting on what I know) are belatedly catching up on some of these)

1. You can't get your malicious package installed by typosquatting or relying on package naming to cause confusion, because every package has two identifiers - a group id that is a DNS name you have to prove you control, e.g., com.google.guava, then a package name - you can publish your gauva package or guava2, but no-one is going to install it by mistake unless you happen to control Google domains. ^(4)
2. There are strict requirements - you must publish source code, docs, repo (even if it's internal) etc. You must include file checksums.
3. You must sign packages with GPG tied to a name and email, and publish your public key
4. Once published, a given version of a package is immutable - it can't be removed, or overwritten
5. The package repository automatically scans all packages submitted for publication for evidence of malicious code, and either automatically rejects or flags suspicious packages for further human review
6. It also analyzes the overall security of your FOSS project (although many of the checks are GH specific currently) and publishes a security score card can be utilized alongside CVE/CWE etc. via a build plugin to reject packages in a build that aren't sufficiently safe.

It's still not 100% secure obviously, if a compromised project isn't using a passphrase for their signing key that is isolated from the build process, or an attacker manages to compromise the passphrase, through, say a developer downloading a fucking Roblox cheat, there's still a risk surface.

But all of the above makes the JVM dependency supply chain a far more hardened attack surface.

Please language maintainers, steal one of the best ideas the Java ecosystem had.

^(1: Java 24 now lets you define an entrypoint as a top level void main() {} not the infamous SomeClass { public static void main(String[] args) {} } that made CS 101 harder than it needed to be) ^(2: Now less of an issue with var and the diamond operator) ^(3: I'm a big fan of compile time DI like Micronaut or Quarkus do - no more loading a massive Spring context to run into tests - but then you could always avoid that if you didn't use field based injection anyway, constructor injection is the only way) ^(4: For people worried the this makes it hard to publish FOSS, there's an escape hatch for people using GH, GitLab etc. https://central.sonatype.org/publish/requirements/coordinates/#supported-code-hosting-services-for-personal-groupid)