There was a somewhat related discussion on hacker news - someone measured how fast a naked javac compiles the project vs how fast the build runs in gradle.
I think it might have been this discussion, though the original blog post has disappeared or moved https://news.ycombinator.com/item?id=42245003 Basically, > From this study we can see the paradox: the Java compiler is blazing fast, while Java build tools are dreadfully slow. Something that should compile in a fraction of a second using a warm javac takes several seconds (15-16x longer) to compile using Maven or Gradle. From my experience, it is **always** better to do a clean build, at least for java parts. The native parts usually take much more time, so some optimization is inevitable. But the larger issue is this - I don't know whether it is even possible to change the gradle build at this point, since the amount of work required to guarantee the feature parity will be enormous, the probability of introducing regression and associated cascading disruption is too great, while the possible benefits are, in my opinion, incredibly small. -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Nir Lisker <nlis...@gmail.com> Date: Tuesday, June 3, 2025 at 09:52 To: Jesper Skov <js...@mada.dk> Cc: Openjfx Dev <openjfx-dev@openjdk.org> Subject: Re: Build logic renovation? Sorry for the late reply, I was stuck abroad due to flight cancellations :) This issue has been brought up before, including lengthy off-list discussions. As a result, I created an umbrella issue that collects issues regarding the Gradle file: https://bugs.openjdk.org/browse/JDK-8344728. The linked issues below are a;ready listed under this umbrella issue. I, like you, was in favor of modernizing the Gradle approach. Johan Vos was in favor of using the OpenJDK approach with config/make, which I'm not familiar with (I only built OpenJDK once and many years ago). I believe the informal verdict is to go with Johan's approach, which I'm fine with. Regardless, the Gradle file does more than building; it also contains publishing: https://bugs.openjdk.org/browse/JDK-8333146 (see the PR in the comments). So, there's more than the build logic to clean up. I've done some minimal simplifications to the Gradle file in https://bugs.openjdk.org/browse/JDK-8345063 (I'm not sure a catalog, as you suggest, would be a big improvement) and https://bugs.openjdk.org/browse/JDK-8344906. Splitting the file for each module (subproject) is also mentioned in the umbrella issue: "Splitting of the monolithic build file should be done with convention plugins. These encapsulate shared code that can then be applied to subprojects as needed." I believe that many of these cleanups still hold value since we'll need to "decipher and translate" the Gradle file to the OpenJDK approach, and it will be easier to deal with it after cleanups. If I'm correct about this, then simplifications to the Gradle build file(s) in some areas could still be welcomed. I'd venture a guess that simplifications that make the code more readable are desired, but maybe those that dig further into Gradle-specific approaches (like the new declarative Gradle or the native plugins) are not. Would like to hear thoughts on this. - Nir On Thu, May 29, 2025 at 8:20 AM Jesper Skov <js...@mada.dk<mailto:js...@mada.dk>> wrote: Ah, good insight! Sounds like a renovation of the Gradle file is not really a move forward then. Cheers! Jesper May 27, 2025, 21:29 by j...@status6.com<mailto:j...@status6.com>: > Hi, Jesper. My comments below are not meant to discourage you entirely from > your plans -- really! :-) -- but rather to help you understand, based on my > own experience, the scope of the work involved. > > On 5/27/25 6:41 AM, Jesper Skov wrote: > >> Would there be interest in reworking the build logic? >> > > Yes, but perhaps more like this: > > Building OpenJFX using JDK > https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/ > >> All the procedural Gradle in one large file makes it hard to understand the >> build logic. >> > > Indeed. > >> It looks very complex. >> > > It is very complex. > >> And it may be performing below optimum (this is just a conjecture). >> > > Without a doubt. > >> I know that the current build is very obviously working. >> > > Barely. :-) > >> And that there may good reasons to keep it in its current form. >> > > No, not really, except for the "very obviously working" part. > >> But if there is an interest, I would like to make the build more idiomatic >> Gradle. >> > > Personally, I'm done with Gradle for any of my own projects. It's difficult > to pin down precisely the way in which Gradle fails to be a good build > system, but I think Bruce Eckel summarized it best in his article below: > > Jan 2, 2021 - 16 minute read > The Problem with Gradle > https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/ > >> Changing the build would be an explorative and iterative task. >> > > The JavaFX build system is remarkably complicated. It is based on Gradle but > also uses other build tools such as Apache Maven, Apache Ant, GNU Make, > CMake, Ninja, GNU GCC, Apple Xcode, Microsoft Visual Studio, and even Windows > batch files. It runs on Linux, macOS, and Windows, and supports eight > different hardware architectures (last time I counted). > > Testing requires you to configure and run hundreds (!) of these complex builds > and unit tests on multiple systems under Linux, macOS, and Windows. > > I'm tempted to say that having (almost) reproducible builds in JavaFX would > help in verifying that you're creating the same artifacts before and after, > but there are just so many artifacts to verify. It's not one build that > produces a set of artifacts. Rather, it's multiple builds that produce > multiple sets of artifacts on multiple systems. > >> And I would need to know if there are some non-obvious out-of-tree features >> that need special handling. >> > > Almost everything in it needs special handling. > >> I can understand if you would be wary about this proposal; I may not be able >> to complete the transition from the current to a new build. >> > > I think you're looking at a multi-year project. > > John >
