Maven is Slow, Gradle Crashes, Mill Confuses Everyone

Maven is slow as shit. Change one line, wait 3 minutes. My IDE already compiled it but Maven doesn't give a fuck, does its whole song and dance anyway.

Same exact build, same machine - sometimes 2 minutes, sometimes 8. Yesterday took 12 minutes because Maven decided to redownload the internet for no reason. Cache was there. I checked. Maven just said "nah."

Tried switching to Gradle. Daemon crashes every other day and uses all your RAM. I've got 16GB, Gradle uses 14GB to build hello world. Kill the daemon, restart everything, still broken.

The Broken Shit I'm Currently Debugging

Right now Maven works locally but fails in Docker. Same JDK version, same everything. Turns out <scope>provided</scope> behaves different in containers. Nobody documents this shit.

Last month tried Gradle. Daemon randomly dies. Spent 2 days figuring out why ./gradlew build used 8GB RAM for hello world. Some moron set org.gradle.jvmargs=-Xmx8g in global gradle.properties. Nobody remembered.

Oh wait, it gets better. Our Surefire plugin broke with JUnit 5.10.1. Works with 5.10.0, not 5.10.1. GitHub issue from 6 months ago, still no fix. Half our plugins are maintained by ghosts from 2019.

Today's Fresh Hell

Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile - Great error message, Maven. Which file? Which line? Stack trace doesn't help. Real useful.

Actually, wait - our Jenkins is now failing with java.lang.OutOfMemoryError: GC overhead limit exceeded again. Third time this week. Kill the daemon, works for 2 hours, dies again. Pretty sure Gradle has memory leaks on purpose.

Oh, and my favorite bullshit from this morning: Could not resolve dependencies for project. I literally added it to pom.xml 30 seconds ago. Maven Central has it. Internet works. Maven's just having a moment. Run again, works fine.

Gradle's build cache corrupted itself again. Tests pass locally, fail in CI. Delete ~/.gradle/caches, magically works. This happens weekly. It's like Russian roulette but for deployments.

Oh right, and Maven 3.8.1 broke everything by blocking HTTP repos. Good security move, but half our Nexus repos died overnight. IT took a week to care.

Gradle 7.0 changed some dependency resolution shit. Builds that worked for 2 years suddenly failed. Fix was some obscure flag buried in random SO comment. Found it after 6 hours.

Why I'm Looking at Alternatives (Besides Being Dead Inside)

I'm just tired of waiting. Builds take longer than my attention span. Make tiny change, kick off build, get coffee, check Slack, debate life choices - still running. My IDE compiled everything 5 minutes ago.

Look, I've tried everything. Mill actually works - cut our 20 minute builds to 3 minutes. Yes, the Scala config syntax scared away junior devs, but honestly that's on them. Bazel is supposedly amazing if you have Google's army of build engineers and infinite time to write BUILD files.

Real talk: unless you enjoy pain, just try Mill first. Everything else is either broken (Gradle), slow as shit (Maven), or requires a PhD (Bazel).

Actually, new problem as of yesterday: Maven fails with The process cannot access the file because it is being used by another process on Windows. Classic Windows file locking. Maven tries deleting temp files before Windows releases them. Fix? Add a fucking sleep. Enterprise tooling in 2025, everyone.

Still haven't figured out why Docker builds randomly fail on Thursdays. Same dockerfile, same everything. Think it's related to some Maven plugin lifecycle weirdness, but honestly gave up debugging it. Just restart Jenkins until it works.

Mill is fast. Like, stupidly fast. Our Maven build was taking 20 minutes, Mill cut it to 3. I was fucking psyched.

Then reality hit during code review. Junior dev needs to add Jackson. In Maven you copy-paste XML. In Mill it's def ivyDeps = Agg(ivy\"com.example::foo:1.0.0\").

What's `Agg`? Why `::` instead of `:`? What's ivy? I spent 2 hours explaining Scala syntax just to add a fucking JSON library. They quit next week.

Mill actually works when it works. Change one file, compiles one file. Revolutionary. Cache doesn't randomly corrupt like Gradle. Uses all CPU cores instead of Maven's one sad thread.

But the error messages. Jesus. "type mismatch; found: String, required: mill.T[String]" - try explaining that to someone who just wants to set a JVM flag. I'm still googling Scala type system bullshit.

Actually hold up - Mill's watch mode just stopped working again. Third time this month. It compiles once, then ignores file changes. Restart fixes it for a while. IntelliJ plugin is hit or miss.

Switched our Spring Boot monolith anyway. 30 minutes to 8 minutes. Worth destroying team morale? Still deciding.

Bazel Almost Broke Me (And My Sanity)

Bazel is what Google uses for their 2-billion-line monorepo. Must be good, right?

Wrong. You're not Google. Google has 20 dedicated build engineers just maintaining BUILD files. You have Steve from DevOps who's already pissed because you broke Jenkins again.

Spent a month getting Bazel working with our Spring Boot app. BUILD file for every directory. Every. Single. One. Want to add a dependency? Better learn Bazel's weird dependency syntax. Want IDE support? Good luck, takes a week to configure.

The builds are fast when they work. 3-second incremental builds are fucking amazing. But debugging errors requires a PhD in distributed systems. "Target //src/main/java/com/example:hello failed to build: invalid label '//external:invalid_target'" - what the actual fuck does that mean? Bazel query language doesn't help either.

Uber switched to Bazel and they're happy. They also have infinite money and dedicated teams. Unless you're dealing with 1000+ modules and can hire Bazel experts, just stick with Maven.

Actually, funny story - spent 3 days debugging why our rules_jvm_external stopped working. Turns out someone updated the Bazel version and it broke Maven jar resolution. Fixed in the next patch but nobody announced it anywhere.

SBT for Java is a Special Kind of Hell

Someone said SBT has better incremental compilation. Thought it'd fix my slow Java builds. Fucking mistake.

SBT's config syntax: libraryDependencies += \"org.scalatra\" %% \"scalatra\" % \"2.6.3\". What's `%%`? Why not just :? Normal syntax is apparently too mainstream.

It's slow as shit for Java. Dependency resolution takes 5 minutes vs Maven's 30 seconds. Why? Because SBT loads all the Scala compiler machinery even when you don't need it.

Classpath issues that only happen in prod. Spent 3 months debugging why our JAR worked locally but died on the server. Turns out SBT packages dependencies differently than Maven. Assembly plugin has its own special rules.

The sbt shell is just weird. Why can't I just run mvn clean install? Why do I need to learn sbt command syntax?

SBT works for Scala. Akka uses it, Play Framework uses it. But for Java? Just use Maven. Don't waste 3 months like me.

Oh, and SBT 1.9.7 just broke our CI because they changed some coursier resolution behavior. Nobody mentioned this in release notes. Found out when builds started failing.

Migration Horror Stories (Or Why I Have Trust Issues)Don't migrate just because you're bored.

I've seen developers break perfectly good builds because they read some Hacker News post about shiny new build tools.Builds take 5 minutes? Don't fucking touch it.

It's working. Junior devs struggle with Maven XML?

Don't torture them with Scala build syntax.

DevOps team is stressed? They'll murder you if you break CI again.

But if builds take 20+ minutes and you spend more time waiting than coding, then maybe endure the pain. Just know you're signing up for months of suffering.### My Mill Migration Nightmare (Still Ongoing)Switched from Maven to Mill last year.

Fucking nightmare doesn't begin to cover it.Week 1: 3 days getting Mill to build our Spring Boot app.

Basic stuff worked. Docker builds kept failing with cryptic errors.

Still not sure why

• something about classpath resolution being different.

Week 2: Rewrote every Jenkins script.

Every. Single. One. Mill outputs to `out/` directories, Maven uses target/.

JAR names are different. Nobody warned me.

Actually, hold on

• Jenkins just failed again. Mill build worked this morning, now it's shitting itself with "Could not find mill launcher script". This happens like twice a week. I think it's related to our Docker image caching but honestly I just restart the job until it works.

Week 3: Junior dev needed to add a dependency.

Maven is copy-paste XML. Mill is def ivyDeps = Agg(ivy"com.example::foo: 1.0.0").

What's `Agg`?

They quit next week. Probably unrelated but timing was suspicious.Current status: Builds are 3x faster when they work.

Mill's watch mode dies randomly. IntelliJ imports the project wrong half the time.

Docker builds work most days. Progress?### Other People's Pain (Makes Me Feel Better)Buddy at Uber worked on Bazel migration.

Took 2 years, hired 20 dedicated build engineers just writing BUILD files.

Now they have 3-second builds for 4000+ services. Amazing until you realize 20 people's full-time job is build config.Tried migrating Java to SBT because someone said better incremental compilation.

Spent 3 months debugging classpath issues only in prod. Assembly plugin packages JARs different than Maven Shade.

Gave up, went back to Maven.Oh, and Netflix apparently has their own custom Gradle wrapper because regular Gradle wasn't enterprise enough.

They have plugins for everything. Must be nice having unlimited engineering budget.### The Shit Nobody Warns You About

Your team becomes useless for weeks learning new syntax. Budget for missed deadlines. Some devs figure it out in days, others never do and keep asking you to add dependencies.Every Jenkins pipeline, GitHub Action, Docker script, deployment script breaks. SonarQube stops working.

Security scanners shit themselves. Checkstyle needs reconfiguration.

It never ends.You discover your app depends on weird Maven-specific behavior you didn't know existed.

Why does JAR packaging work different in Mill?

Why does Spring Boot plugin behave weird?

Good luck debugging.Actually, speaking of debugging

• our Jacoco coverage just broke again after migrating to Mill.

Works locally, fails in CI. Different coverage reports. Mill's equivalent generates reports in totally different format.

DevOps is pissed.### Reality CheckMigrate if you spend more time waiting than coding. Don't migrate if builds work. Sometimes you migrate because Maven downloading the internet for the 100th time finally broke you.

Sweet spot: 10-30 minute builds.

Slow enough to annoy, fast enough that alternatives help. Should measure performance first but most of us just switch out of pure frustration.

Actually, hold up

• Mill just crashed with "java.lang.NoClassDefFoundError: mill/api/Ctx$Log$class" during our morning standup demo.

This is the third time this month. GitHub issue exists but no fix yet.

Welcome to the cutting edge.