Gradle is one of the fastest build systems out there (certainly the fastest for Java projects because the tight integration with the compiler), given people know what they are doing. Most often than not they will write build logic as configuration which runs each time.

But when configured properly, it actually has parallel builds, with fine-grained build dependencies, so only the actually changed classes will be recompiled.

If it wasn't for Google's sponsorship it would have been gone by now.

Android is probably the only platform whose conferences to this day have a sessions about improving build times, thanks Gradle.

When doing Windows CE, Pocket PC, Windows Phone 7, WinRT, Symbian, iOS, I never needed a gaming rig as development workstation.

It is android’s fault, not gradle’s.

When Gradle requires a background daemon consuming at least 2GB and SSD disks to achieve usuable builds, that lies on Gradle not Android.

Why exactly? It stores caches, that gets used for the build process. How else should it operate?

The problem is the amount of dependencies/build tasks, not the tool managing those.

The excuses with Gradle are always the kind of "you're holding it wrong".

Thankfully outside Android, I never have to put up with it on regular Java projects.

Which would show you how is it a very fast build tool, but if you prefer not even learning about it, do stay in your ignorance.

Yet again the "holding it wrong" and "you're an ignorant" argument that always comes up from Gradle people.

Yeah, it is very fast, when one has all the knobs to help Gradle pretend it is fast.

I have been setting up Java CI/CD pipelines since 2005, have used all major CI/CD products in the Java world, including your beloved "blazing fast" Gradle.

Yeah, don't do that.