Being an Android developer, I’m not only chained by the arbitrary whims of Google when it comes to API changes, I’m not only chained to older versions of JVM, I’m not only basically forced to use Android Studio, I’m also forced to use Gradle. Google force you to update to newer versions of the Android API if you want to upload to the play store, which means you may need to upgrade your Android Studio, which may mean you need to upgrade Gradle.
While Gradle looked real neat when it first came out, much simpler to read than the XML fest that is Maven, as time has dragged on, so has the cracks in the Gradle walls started to show. It can’t be understated what an absolute pain in the ass it is to have to work with.
This is absolutely nuts and the biggest reason I hate Gradle. I don’t see a single reason why upgrading Gradle means your current gradle configurations stop working. Sometimes the changes are absolutely asinine - keywords changing in the configuration file, and later versions not accepting the old keywords.
Here’s another example of just randomly breaking builds, from the same page I just linked to:
test {
options {
}
useJUnitPlatform()
}The above block set some options for performing tests, then picked to use JUnit to run them. The kicker is, they decided that this will now cause an error and break the build, because it’s now supposed to look like this:
test {
useJUnitPlatform()
options {
}
}You hunt down cases like this every time you upgrade Gradle. They can’t help themselves at Gradle Inc - It’s some kind of itch in their fingers, or the spasms of an alcoholic in withdrawal, they just must introduce changes like this. Here’s their rationale:
When configuring the built-in test task for Java, Groovy, and Scala projects, Gradle no longer allows you to change the test framework used by the Test task after configuring options. This was deprecated since it silently discarded configuration in some cases.
Know what the solution for this is? Don’t discard configurations silently! If the silent discardment of configuration happens outside of Gradles control because the test framework messes with them, then throw a warning instead! Change how things work under the hood and don’t touch userspace.
Want any more examples of this? Their documentation is overflowing with cases they caused themselves. Usually, they demonstrate how to fix the problem, which is presented like a fresh gradle configuration straight out of a brand new IntelliJ project. Knowing how to apply these changes to your 8 year old Gradle project that has gone through 4-5 development teams of varying Gradle competence, is often a massive undertaking which usually results in a suboptimal, slow and prone to break configuration.
XML in Maven sucked, but it was dead simple. You could copy paste from anywhere and it would work in your pom.xml. In fact, you wouldn’t need to hunt down in which file you should paste, because there is only one.
Gradle has the following files in a very simple project:
build.gradlegradle/wrapper/gradle-wrapper.jargradle/wrapper/gradle-wrapper.propertiesgradlewgradlew.batsettings.gradleThat’s just a simple Java project, in Android you may have many more files than this. In which file do you think you specify the JDK version? Or which JRE that you use to run Gradle? Where do you specify which version of Gradle to use? See, it’s not that difficult to hunt down, but you still need to do it. It’s not all in one file. XML may look like shit, but there are plenty of XML viewers out there that present it much more nicely. Gradle is ass no matter how you read it, because the message is the same - fuck you.
What the fuck is Groovy? It’s a scripting language. By itself, it’s not that bad. It’s kind of neat. If you want to write scripts that easily interop with Java code and don’t mind spinning up a JRE to run them, it could even be quite nice.
But we’re not making scripts. We’re configuraing a build system. We’re defining dependencies. We don’t need to parse incoming JSON, or work with a database, start servlets or whatever else. We define that we need so and so to build our application, which tests to run, where the compiled files should land and where the source sets are. We definitely don’t need this power - and as the saying goes, with great power, comes great complexity. This will come back and bite you in the ass when something looks simple in text, but under the hood involves a lot of gears biting together, which they often don’t, slowing down everything. Sometimes to a halt.
This is even more weird to me. Not only do you split your community with some people using Groovy and some using Kotlin, making snippets more difficult to share because they may not apply in your configuration, we still have something that is way too advanced for how simple it should be.
Another problem with these complex languages is that there is more than one way to do things, which is piss poor for discoverability. You ask 5 people how to only run some tests depending on the build flags, or to only include certain dependencies in some cases, you get at least 6 answers. This is where you expect the one same answer from everyone, which is the same way everyone does it, so the next time someone joins your project or you join theirs, you can tell what’s going on. Not so much with Gradle.
Ties into the above points. Nobody knows how to make idiomatic configurations, some people are way too clever for what they’re doing, so your computer starts sounding like a jet engine just piecing together a couple of Java files. I’m sure Gradle burns more CPU cycles than the actual program would.
Here’s where some people expect metrics - yeah, no. Some Android applications I know take more than 15 minutes to build, because of Gradle spinning in circles on the floor. This is even after a bunch of optimizations. I don’t mind if a simple tool takes its time to do what it’s supposed to, but Gradle is not simple.
I recently migrated one of my hobby projects to Maven. I don’t need to worry about breaking changes anymore, finding resources on how to do things with Maven is very reliable. I’m also confident I can just build my project 10 years later without needing to mess with my configuration files.
It’s sort of going from a hand-me-down hobby Italian race car that spends more time in the shop than on the road, to a 90s Toyota Corolla. Don’t lie to yourself about which one actually brings you places.
Are you working with Android? Tough shit, but at least you’re already used to being bent over on a daily basis. The daring adventurers at Google work hand in hand with the sadists at Gradle Inc to maximize your pain, so you’re in for it.