Hacker News new | ask | show | jobs
by dgreensp 1267 days ago
I was developing in Java right up until Maven became popular. We used to just download jars. What would you say is the main difference with Maven/Java vs NPM?

My recollection is that Java libraries were larger, higher-quality, more stable, and better-maintained, and you didn't need as many of them. A Java jar was not a "package" but contained dozens of "packages" developed together. Jars tended to be self-contained or mostly self-contained; small dependencies would shipped inside. The idea of making npm packages as small as possible, like practically putting each file in a separate git repo, and publishing it as a separate artifact, emerged shortly after NPM itself, and it was radical, and not really particularly good. Java also has a much larger standard library, and between the packages that come with Java itself, the packages that aren't technically part of the standard library but were written by Sun/Oracle, and well-known third-party utilities, you didn't need a lot of third-party packages. And if you needed something tiny like left-pad and didn't have it, you'd probably just copy and paste it.

1 comments

> What would you say is the main difference with Maven/Java vs NPM?

Maven doesn't allow execution of arbitrary code at install-time, which curbs a large number of potential supply-chain attacks.

Because of the JVM and JARs being mostly self-contained Maven doesn't really need to worry about system or runtime dependencies (unless you're using Scala...). This allows Maven to be a 'dumb' package manager that relies on simple semantics (no hidden specially-generated indices, for example) and be fairly successful. Of course, there's an internal battle of whether Gradle or Maven is superior, but they both rely on the same distribution and packaging specifications.

Maven doesn't have this problem because maven central is too obtuse for hackers to use, and Enterprise Java developers don't ever update their dependencies. It's actually to their benefit, but it's for the wrong reasons.
> Maven doesn't have this problem because maven central is too obtuse for hackers to use

I have many gripes with Sonatype but Maven Central isn't really one of them. The fact you can publish a packages to the likes of PyPI, npm Registry, or Docker Hub with 0 friction makes those places very attractive to spammers and bad actors. Maven Central having a higher barrier of entry is a feature.

IIRC Brian Fox, the CTO of Sonatype, was actively involved with Maven in the early days and was part of the decision for Maven packages to use domains for namespaces. Namespaces are another valuable feature of Maven that makes supply-chain attacks like typo-squatting harder to pull off.

The real reason was the second one. That was just a cheap dig at their UX. Both were cheap digs, but also both true.
Lol, I knew you were mostly joking — but you also weren't wrong.

At the same time, some people genuinely shit on Maven Central and think that it's inferior to other registries.

There's a real problem with maven central and java in general that there's no correlation between the package name - which is nicely domain-name formatted - and actual domain names. If there were a clear "this is really thai domain name and DNS verified" and "this is compatible but not DNS verified" marker, it would be great.

I think golang has the best answer for this, where it's easy to impersonate but it has to be explicit.