Hacker News Reader

Comment by crossroadsguy | Hacker News Reader

Gradle had a lot to do with my attempts to move away from Android development. Well, not that other tools are shiny beacons of goodness, but still Gradle takes the cake effortlessly.

View on HN

I feel you. Gradle is the reason why I stopped updating my opensource android projects and killed them. I once got updates to translation files, wanted to update gradlew as it was ~2 years old. Failed with updates for +16 hours spent on it. Multiple gradle functions replaced or removed, dozen of incompatible changes, broken syntax, incompatible gradle plugins I used for C compilation... I simply gave up, archived the repo, stopped accepting translations and moved away from Android. Simply too much effort was wasted trying to keep dependencies up to date every year or so.

Just look at some of these breaking changes reported for 7.0:

    [#16652] - Trouble using centralized dependency versions in buildSrc plugins and buildscript classpath
    [#16620] - FileNotFoundException in TestKit tests: lib-android/build/20210320_1519030999411730848.compiler.options
    [#16541] - Impossible to run modular program with 7.0-milestone-2. Working with 6.8
    [#16532] - Build failure when including a plugin build in settings & applying a settings plugin
    [#16163] - Using included builds for local settings plugins don't seem to work
    [#16028] - Change in behaviour when resolving custom project dependencies

I without going into details, two of these would affect the project I talked above... These breaking changes should be enough to block release of 7.0 before 100s of developers are hit by these time-wasting issues.

Also seems like a horrible idea to use a custom DSL for the configuration. Just another curveball to throw at you.

XML, yaml, toml, json, something else standard and well known would have been nice.

I don't think this criticism makes much sense. XML, yaml, toml or json would replace the current choice of Groovy or Kotlin, but the actual configuration would be just as much of a DSL.

Yeah, a build specification is essentially a DSL.

It's only really "custom" if you don't know Groovy. Plenty of build systems invent a whole custom language for it so it is one step better than those - at least by the time you do learn groovy you have picked up a transferrable skill.

I do think that one of the big problems with Gradle is they try to operate under a pretense that you don't need to learn any Groovy to use it. The reality is you can get just far enough to get yourself in trouble and then suddenly you are mired in inexplicable problems, and just start hating the tool.

I mean, it is only really NOT "custom" if you have even considered using Groovy for anything other than Gradle; and like, while I remember there were people who seriously thought Groovy was "the future" 15-20 years ago, they were wrong.

I wouldn't agree with that. Custom would imply there's literally only one purpose for the language. Groovy has a lot of relevant applications outside of gradle scripts. It's great for testing any JVM language, the basis of things like Jenkins pipelines, a generally useful extension language to embed in any JVM based software, and a myriad of other potential uses including full application development as a first class JVM language. Just because you personally wouldn't prefer to do those things doesn't change the general nature of what it is.

Kotlin is an alternative now, and it's great.

Gradle has unfortunately gone the way of Maven in terms of becoming more and more of an unnecessarily complicated time sink.

I have the exact opposite experience. Been on tens if not 100+ Java projects over the last 20 years and 99% of developers I worked with moved away from Gradle after migrating to it from Maven. It's just harder to work with. Maven is super low-maintenance in comparison (and just works).

And Maven makes writing custom build logic just hard enough to discourage people from doing so, which is a very good thing, from my experience of having worked with Gradle for 5 years or so.

The irony about Gradle is that it is Ant all over again, and on top of that slow as a dog, unless oen allocates several GB for a background daemon.

At this point Ant + Ivy is probably better :-D

Actually for anyone without XML allergy it definitly is.

You get IDE completion, script debugging support, it is fast and best of all, it doesn't change in every release.

Maybe that is the case if you are working on a project that is large enough to have a dedicated build engineer who stays on top of the Maven situation. But in my experience Maven has been an absolute nightmare to work with for me and others on the teams that I have been on. I don't know how many days have been lost to trying Maven to do one simple thing correctly. And I can tell you that more than once was I eventually so fed up that resorted to using the Ant plugin. That was usually able to solve a problem in five minutes that I had already spent a day on trying to get Maven to cooperate.

That being said, when I switched over to Gradle almost ten years ago, it was still only a marginal improvement, but an improvement nonetheless. Unfortunately, things only seem to have gone downhill from there.

You represent the 1% of java developers who think Gradle is better than Maven. And that's OK because as with everything else there is an element of personal preference to everything.

But that doesn't change the fact that overwhelming majority of professional java devs avoid Gradle like the plague.

And no, we don't have a dedicated maven guy in every project. Maven is just too simple and well understood for that.

To support java 16 all I had to do was change the release tag in my compiler plugin and everything just worked. Didn't have to ugprade maven, didn't have to upgrade the compiler plugin. Gradle users had to wait until they released another entire major version with all the churn that entails.

Gradle has support for running and building with different JDK versions (it's not new with Gradle 7 but it's a recent feature).

So it was possible to support building Java 16 projects while running Gradle on a supported Java version before Gradle 7 was released.

https://docs.gradle.org/current/userguide/toolchains.html

Doesn't really seem like what you are saying is true: https://github.com/gradle/gradle/issues/13481.

I'm guessing you only read the issue or title on that link, because the second comment on that issue is from one of the Gradle maintainers suggesting using toolchains (which I linked to), with follow ups from various users advising some success, allowing them to target Java 16 while running Gradle on an earlier, supported version.

The last comment by a gradle team member, before closing the ticket says "... you won't be able to run Gradle 6.8.x on Java 16". Some users having some success compiling isn't really a ringing endorsement of a build system when it's clearly not working completely.

> "... you won't be able to run Gradle 6.8.x on Java 16"

Exactly. But you could run Gradle on Java 8-15 and use the new toolchains support to build with Java 16.

I'm not saying setting up toolchains is frictionless or even reliable yet (given the feature is so new) but it's there.

Sorry, but maven is an order of magnitude better than gradle. In most cases it just works and is blazing fast compared with the alternatives.

When Gradle advocates tell it is faster than Maven, they usually let it off that Maven doesn't require a backgroud daemon eating away GBs to be fast.

Why is it a problem exactly?

> eating away GBs to be fast.

Make something fast, cheap, stable; choose 2.

Gradle is none of those three.

The problem is that it is super easy to modify a Gradle build scripts, but also super hard to get it right (e.g. understanding of configuration vs. execution phase, concept of configurations, task dependencies). As long as you don't touch the build script, Gradle is superior to Maven in _so_ many ways.

Yes, it has what I would describe as a cliff learning curve and I think that is it's biggest drawback. One understands Gradle or one doesn't and that is pretty far from ideal.

Thanks to Gradle, Android is probably the only platform where there is always a talk about how to improve build speed for the whole platform.

Do you think Scala, Rust or C++ build times are bad? Wait until trying a medium sized Android project with Gradle, without using a gaming rig.

I did the same, Android now only via mobile Web or NDK.

Reply on news.ycombinator.com