On Tue, 22 Sep 2026 17:01:21 GMT, Andy Goryachev <[email protected]> wrote:
>> Gradle tries really hard to avoid doing work, which significantly speeds up >> repeated builds. But that only works if Gradle can precisely track the >> inputs and outputs of tasks, which it can't do if we're invoking another >> build system. > > it also adds significant overhead [0] and a maintenance burden. > > [0] https://mill-build.org/blog/1-java-compile.html > I don't quite get this aversion to `ant`. `ant` is not aware of the build around it. As a result, it doesn't reuse code so it's very verbose and it's much slower since it does no caching or parallelizing. It just executes the same thing every time. Try to write a build for JavaFX with `ant` and with Gradle and you'll quickly see how Gradle does almost all of the work for you. > This build file worked without changes since probably 2014 Which one? The one in this PR is completely new. > yet with gradle we had to go through upgrades, additional build steps... Because JavaFX proper changed and these manual tests didn't. These tests were not modularized unlike the JavaFX modules, JavaFX got new modules and these tests didn't, and we chose to update the Gradle versions but not the `ant` version. If you keep the Gradle version at 4, it will also work with no changes, why update it? When was the last time `ant` was upgraded in JavaFX? According to my file system, not since 2018 at least (version 1.10.5). Besides, the Gradle build of JavaFX runs an ant-like script to build everything, Gradle isn't exactly invoked, it's more of a shell. It was written incorrectly and eventually it will need to be fixed, which is what I'm trying to do. The complaints you're voicing are akin to the "Java is slow" mantra coming from people with a badly written Java program written in 2004, and then saying "I don't get the aversion to Fortran, I never needed to change it". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2156#discussion_r4074346204
