On Tue, 22 Sep 2026 18:05:57 GMT, Nir Lisker <[email protected]> wrote:
>> To Nir's point, this isn't an existing build script. There are no build >> scripts for manual tests and all of our other tests use gradle. Right now, >> only "apps" use ant, and that's because they are legacy. I wouldn't use that >> as an argument for expanding the use of ant beyond the apps dir. > >> All my builds are clean builds, I had my share of problems stemming from >> stale artifacts. > > Yes, because the Gradle build file is incorrect. I filed > [JDK-8391666](https://bugs.openjdk.org/browse/JDK-8391666) because the stale > artifacts aren't detected correctly, which results in compromised builds. > [JDK-8389921](https://bugs.openjdk.org/browse/JDK-8389921) fixed an example > of this with native sources. With all of that, it's still rare that I need to > clean every build. > >> Do you want to migrate all the build scripts in the project to use gradle? > > Without fixing the main build file it won't help much because these > apps/tests are downstream of the broken build. They'll run a bit better than > ant. I have https://github.com/openjdk/jfx/pull/2294 sitting in the review > queue for a couple of weeks (not complaining), and > https://github.com/openjdk/jfx/pull/2305 ready to go in directly after. Then > a couple more in the chain that I'm waiting with until the first one moves. > it also adds significant overhead [0] and a maintenance burden. > > [0] https://mill-build.org/blog/1-java-compile.html That's because it's an actual build system, and not an artificial benchmark that shows anything and nothing. Once you solve all the problems of a complex build, you _will_ have a complex build script and the artificial advantage goes away. In fact, ant is _much_ slower than Gradle on very complex builds once you account for repeated edit-and-build scenarios. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2156#discussion_r4074874946
