Gradle was really not that great back around v3. It was using a ton of my ram, and required frequent cleaning, it was just as bad as Maven in that regard. I thi

Gradle was really not that great back around v3. It was using a ton of my ram, and required frequent cleaning, it was just as bad as Maven in that regard. I think it has improved by lot since then - or maybe thats stockholm syndrome speaking ;) or maybe it's because I stopped doing Android stuff. In any case, one of the large problems remaining is the bad discovery of stuff-it-can-do-and-how-to-configure-that, and making it too easy for devs to write imperative code when they should be staying declarative. Also, I don't very much like how complicated some of the newer features are to use, and how much weird magic they require to be turned on / configured. Another thing I absolutely hate is how it splatters the build scripts into half a dozen files. Personally, even for large monorepos or multi-module builds, I prefer to have one huge script file + plugins. The strengths of Gradle, if the scripts are written properly, however are very clear to me: - Task avoidance and therefore crazy good build speedup ofc that requires tasks to be well defined, ideally the whole project to be split up into smaller modules, and each of the build tasks being deterministic. unfortunately many devs don't understand how to do this, and some of the more exotic build steps in monorepos might not be properly deterministic (looking at you, frontend build tools) - It can be wrapped around other langs and exotic build steps for monorepos. E.g. you can first fire up a database in a container, and run your migrations against that, then use the resulting schema to generate your database entities. In parallel, you might want to run some protobuf generation, that is then used by e.g. a Java backend and a JS frontend built that's actually using yarn in the background. There are plugins available that will wrap the yarn scripts to the Gradle lifecycles. The output of the frontend can be used to be included in the static files of your jar, which you can fire up for tests with browsers running in docker containers and doing e2e tests from the Java BE code, so you can do amazing test setups. Gradle can do all of that, with incremental builds / cached in- and outputs. Imagine having to keep all these steps in your head and running them on-demand when you think its necessary. Or running them every time no matter what (looking at you, Maven) Gradle allows me to write down all of these steps as individual, declarative tasks, making use of a vast and high-quality plugin ecosystem. Then wire up their order, again, declaratively. Once that is accomplished, I can turn off my brain and focus on building code and don't have to know which parts needs to run when exactly. When I joined one of my previous teams, they were using a rube goldberg machine of Bash, AWK, Python scripts with a lot of JSON slurper and AWK sprinkled in to manage multiple modules in different repos into a monorepo-like state with individual releasing and versioning. With Gradle, that was much easier to accomplish: The dependency resolution rules could be written as simple code with easy and well defined conditionals, instead of manipulation of Maven pom files during random build steps. Also introspection into the build dependencies allowed an easy way to find out which projects dependend in which other ones. (Now was doing all of this a good idea in the first place? probably not :) but they certainly didnt allow themselves to be stopped by Mavens inflexibility, and the resulting horror of a build pipeline was certainly worse then writing all of that in Gradle) In think, in the end, for small projects, Gradle isn't that benefitial. Maven can accomplish simple builds with no special rules and no necessary task avoidance just as well as Gradle, if not better due to the restrictions. But once you need to build something bigger (did someone say Enterprise?), Gradle starts shining - as long as you tread carefully.