Hacker News Reader

Comment by Eddygandr | Hacker News Reader

Stack vs Cabal was a huge argument where I worked with multiple teams using different build tools. Add Nix and nix2whatever, and it was more fun. Spent half my time debugging build instructions

View on HN

It is not that much better in Java land. Getting builds right takes lots of resources, keeping new and old things running is not trivial.

I haven't had that experience for newer code bases. Yes, there's some ancient "works only in my IDE" stuff but that's really not how modern Java is written.

Yes, there is a disagreement about whether to use maven or gradle, but IMHO they both work reasonably well out of the box.

In my experience, if you have to build an older maven project, you have to go through a lot of painful hoops, mostly around HTTP vs HTTPS repos and java source/compiler versions. I have encountered many old projects that don't build out of the box, and of those, I've only managed to get about half working.

Right now, things are pretty good. But this is surprisingly recent. Gradle and Maven have both been good at managing dependency versions for a long time. Gradle has also been good at managing the Gradle version, via the wrapper, for a long time; Maven has equivalent wrapper now, but it's quite new, and support in the wider ecosystem is patchy (eg a TeamCity Maven build step can't use a wrapper, i don't think). Meanwhile, there is no standard way to manage JDK versions; there are SDKMAN! and asdf, and they work fine, but they aren't de facto standards. Gradle lets you specify the JDK version to build with via toolchains, but this is quite new (6.7 in 2020). I have no idea if Maven has an equivalent.

While what you say is true, the point about the JDK versions is mitigated a bit by the fact many things are backwards compatible. Although yes, if you jump from 8 to 17, you're going to run into some problems.

I'm not a huge fan of the gradle toolchain tool (I don't think gradle should be managing my JDKs and I would prefer if it could instead just fail the build if you use the wrong JDK version), but I do understand why it exists.

Yes. I've been in teams where there has been gradle vs maven arguments.

Right now the Mac (M1 or M2) users in our team can't run our integration tests. It has been suggested that if we migrate our 50-100 services to Java 17 then the tests will work for them again. Trying to do this breaks the Gradle scripts, and the errors are so vague I can't tell why it's complaining.

While I understand what you're saying, the "XY doesn't work for mac users on M1/M2" is a really pervasive problem across all technologies.

Reply on news.ycombinator.com