4 ms·

Show HN: Gradle plugin for faster Java compiles

38 points by sgammon 1y ago

Hey HN, We've written a pretty cool Gradle plugin I wanted to share. It turns out if you native-image the Java and Kotlin compilers, you can experience a serious gain, especially for "smaller" projects (under 10,000 classes). By compiling the compiler with native image, JIT warmup normally experienced by Gradle/Maven et al is skipped. Startup time is extremely fast, since native image seals the heap into the binary itself. The native version of javac produces identical outputs from inputs. It's the same exact code, just AOT-compiled, translated to machine code, and pre-optimized by GraalVM. Of course, native image isn't optimal in all cases. Warm JIT still outperforms NI, but I think most projects never hit fully warmed JIT through Gradle or Maven, because the VM running the compiler so rarely survives for long enough. Elide (the tool used by this plugin) also supports fetching Maven dependencies. When active, it prepares a local m2 root where Gradle can find your dependencies already on-disk when it needs them. Preliminary benchmarking shows a 100x+ gain since lockfiles prevent needless re-resolution and native-imaging the resolver results in a similar gain to the compiler. We (the authors) are very much open to feedback in improving this Gradle plugin or the underlying toolchain. Please, let us know what you think!

jart 1y ago
OK let's say I have an online store I wrote in Spring Framework. What does my before and after development workflow look like after adopting your plugin? It's been a while since I've messed with Java, but how many seconds could it possibly need to fetch a bunch of jar files? I'd love to see an in-the-life-of kind of screencast of what the daily grind looks like for normal java devs these days, so I can understand why it's so slow. For example, what does resolution mean? Does that mean fetching the pom.xml files from sonatype to figure out the dependency graph? Don't those HTTP requests normally go fast? Is Elide sort of like setting up an HTTP caching proxy between corp and sonatype?
- sgammon 1y ago
  > OK let's say I have an online store I wrote in Spring Framework. What does my before and after development workflow look like after adopting your plugin? Basically, you install this plugin, and it tells the `JavaCompile` tasks normally used by Gradle to `isFork = true` and use `elide javac -- ...` for the compile command. So, javac invocations travel over the CLI instead of through the Tooling API, which Gradle normally uses, and which is effectively running in Gradle's daemon VM, and thus is subject to JIT warmup. Through Elide, since it's a native binary, all that JIT warmup is skipped, and you are effectively choosing to balance more toward quick startup and wall-clock time (with many small calls) instead of waiting for JIT warmup to make the Gradle daemon fast with javac. Otherwise, it's a completely identical javac experience. Running `elide javac -help` produces identical help output. Identical inputs should produce identical outputs, and we build it at JDK 24 so it can support `--source/--target/--release X` and friends for anything older down to JDK 8. > For example, what does resolution mean? Does that mean fetching the pom.xml files from sonatype to figure out the dependency graph? It means resolving the graph from declared (direct) dependencies, downloading pom.xml metadata, downloading JARs, unpacking it all to disk, and providing a local `.m2` Maven-compliant root, sort of like Node does for `node_modules/`. Ours lives in `.dev/dependencies/m2` once you run `elide install`. Elide embeds Maven's resolver, so resolution semantics are identical to Maven's. We do some small optimizations to make fetching fast (i.e. initializing related classes at build time, that sort of thing), but honestly not much. Just building Maven's resolver like this yields a major gain, and not messing with it preserves expected behavior. Since Elide emits these deps in a Maven Local-style root, Gradle just finds them on disk when it needs them, so it doesn't need to engage its resolver or fetcher at all. > Don't those HTTP requests normally go fast? It is worth noting that Gradle seems confined to HTTP/1.1 and poor connection pooling even today, so it's not that hard to beat. > Is Elide sort of like setting up an HTTP caching proxy between corp and sonatype? We don't proxy or anything, this fetching still happens through normal Maven Central unless configured otherwise in your `elide.pkl` manifest. For now, deps are placed in the local project, but we want to move to a central cache and link like modern NPM installers do.
  - sgammon 1y ago
    (Oh, if you are seeing how the plugin installs a Maven repository, that's just to ship our own plugin artifact and Gradle Catalog, for easy dependency use. maven.elide.dev doesn't proxy to central or anything like that.)
sgammon 1y ago
Volker Simonis over at Amazon did some very cool benchmarks showing the impact this can have (i.e. native-imaging javac): https://github.com/simonis/LeydenVsGraalNative https://github.com/simonis/LeydenVsGraalNative
alisonatwork 1y ago
Hypothetically, if you could daemonize javac, would JIT eventually kick in over multiple recompiles of the same code? The obvious use case for this would be IDEs, but I imagine it could work in CI too if you had some kind of persistent "compiler as a service" setup that outlived the runners. Not to detract from the cool work done here, just curious if this other approach has been tried too.
- sgammon 1y ago
  > Hypothetically, if you could daemonize javac, would JIT eventually kick in over multiple recompiles of the same code? This is actually how Gradle works by default; in fact, even if you pass `--no-daemon`, it will start a daemon, and just kill it after the build (lol). It's daemon-first, daemon-only, because of this exact issue. As I understand it, Gradle's daemon timeout is typically 10 minutes, but can be extended. We are guessing that this style rarely hits the 10k class threshold where JIT performance converges with native, especially since Gradle also supports incremental compilation, and that further impedes the progress toward a warm JIT. Gradle focuses hard on build caching and incremental compilation, and this is conceptually in contention with reaching a warm JIT, ironically. Native Image has JIT capabilities (just not as mature as Hotspot yet), and keeping the daemon alive would probably still yield wins. We haven't tried it yet and that's a good idea
  - alisonatwork 1y ago
    I'm aware of the Gradle daemon, but wasn't sure if it only handled dependency resolution and other build orchestration tasks or if it also ran the compiler in the same JVM instance. Last time I worked somewhere using Gradle I think we forked the compiler anyway to ensure the project was built on exactly the same Java version regardless of what the Gradle environment was running in, so in that case there is definitely room for startup optimization. I do recall the Gradle daemon living much longer than 10 minutes, though. The docs say 3 hours is default, although if really trying to maximize the JIT advantage it perhaps would make sense to keep it alive as long as possible.
    - 1y ago
kristianp 1y ago
So elide is a tool to run {js|ts|py} [1]. How does it compile javac to native? [1] https://github.com/elide-dev/elide https://github.com/elide-dev/elide
- sgammon 1y ago
  In addition to being a runtime, Elide embeds `javac` and `kotlinc`. Here it is being used as a build toolchain, but it can also run those languages, through GraalVM/Truffle.
- sgammon 1y ago
  (In other news, I've added Kotlin to the list there, as {...|kt|kts}, so thank you for reporting this as well! We really need some docs updates and I'll make sure to clarify this stuff)
- mdaniel 1y ago
  What.is.happening.here. Are they committing node_modules or something? $ git clone https://github.com/elide-dev/elide.git Receiving objects: 100% (126086/126086), 643.85 MiB | 3.02 MiB/s, done.
  - sgammon 1y ago
    There are some JARs we must commit to source because they are built with patches from upstream GraalVM components. That's probably the big weight there. We have an issue in our repo tracking those upstream PRs. Once merged, we won't need to do this anymore. We should probably publish them in our own Maven repo to avoid this kind of experience. Thanks for the push to take care of that cruft :P You can find them in `third_party/oracle`. You also don't need to build from source -- Elide ships as a binary for Linux amd64/macOS arm64. You are totally welcome to though, and if you encounter issues, hop in our discord and we'd be glad to help: https://elide.dev/discord https://elide.dev/discord
linksbro 1y ago
Would this result in the same .class that javac produces? I.e. at runtime is code compiled with this fundamentally different than code compiled with javac?
- sgammon 1y ago
  This results in identical .class bytecode that `javac` produces, yes, because it's literally just `javac`, but built as a native binary instead of a Java entrypoint. We build at JDK24 and support `--source/--target/--release` so you can build against earlier JVM targets. If you find any output differences between Elide and JDK24 (Oracle GraalVM), then we'd consider that a bug. Similarly, we accept identical compile flags and emit identical warnings/messages, as under the hood we are just using the same compiler APIs but natively.
re-thc 1y ago
Interesting idea. I wonder how this would compare to native-imaging Gradle or Maven itself.
- sgammon 1y ago
  Elide's resolver is just Maven's, and we use Maven's own components to read poms. Native-imaging Gradle itself is really challenging because Gradle relies so much on reflection, and really is architected to account for the JIT case (i.e. emphases on the daemon). I haven't found a way to do it yet so this plugin is the best alternative so far.
normie3000 1y ago
Is there an equivalent maven plugin? Also what's the licence for elide?
- sgammon 1y ago
  Not yet, but we are working on a Maven plugin :) if you join our Discord or file an issue, I can update you when its out. Elide is licensed under MIT https://github.com/elide-dev/elide https://github.com/elide-dev/elide
rjwalters 1y ago
Do you have benchmarks? How much of a difference does it make?
- sgammon 1y ago
  Benchmarking a toy case (hello world) shows a 20x performance difference; this is true for both kotlinc and javac, when benchmarked through hyperfine. YMMV, but benchmarks of different build styles show native converging with JIT at about 10k classes[1] So, if your project is 10k classes or less, you are looking at "up to" a 20x improvement in compile time vs. stock javac. On the dependency fetching side, we haven't benchmarked yet. It definitely feels like 100x+ though on a wall-clock basis. [1]: https://github.com/simonis/LeydenVsGraalNative https://github.com/simonis/LeydenVsGraalNative
Zardoz84 1y ago
interesting. I wonder how compares against mavend (mvnd , aka maven as a Daemon service) and his aggressive parallelization.
pjmlp 1y ago
Personally the solution to faster build times in Gradle, is to keep using Maven. I never touch Gradle unless there is no way around it, like Android. However, this looks like an interesting idea.
- gerardnico 1y ago
  Exactly, gradle is so slow that I ditch it into the ground. Just starting a blank project is so a bad experience. Nothing beat maven and a couple of shell script.
  - pjmlp 1y ago
    I am convinced if they hadn't got Google's sponsorship, when Android decided to move into Gradle during Eclipse to InteliJ migration, we would be talking about Gradle as much as Grails is still discussed at local JUGs.
    - kasabali 1y ago
      Same, but also for Kotlin
      - pjmlp 1y ago
        Agreed.
- Postosuchus 1y ago
  This. And speed aside, Gradle embodies everything that is wrong with modern software development. A giant, opaque, idiosyncratic black box. I develop for Android (Java and Flutter) and it has become a sad pattern from Hell: Android Studio update mandates upgraded Gradle, which breaks previously the build in most weird ways, forcing one to trawl StackOverflow looking for proper incantations to do in the myriad of files it has created with the single purpose of building the damn app. Sometimes I wish, creating new build systems was outlawed some time after gmake or cmake...
lemming 1y ago
The underlying Elide tool looks amazing, and potentially solves all sorts of pain for me. Does the Kotlin compiler support plugins, e.g. serialisation? I can imagine they might be too reflective.
- sgammon 1y ago
  > The underlying Elide tool looks amazing Thank you! > Does the Kotlin compiler support plugins, e.g. serialization? We don't support Kotlin Serialization yet, but KotlinX is fully embedded and ready. You can reach for things like KotlinX Coroutines without installing a single JAR. Bring-and-use-your-own-plugins might be challenging, yeah, but we plan to at least build in the KotlinX plugins you would want by default (serialization included). So thank you for this note, it's helpful and I'll add a notch next to that feature :)

38 points by sgammon 1y ago

jart 1y ago

OK let's say I have an online store I wrote in Spring Framework. What does my before and after development workflow look like after adopting your plugin? It's been a while since I've messed with Java, but how many seconds could it possibly need to fetch a bunch of jar files? I'd love to see an in-the-life-of kind of screencast of what the daily grind looks like for normal java devs these days, so I can understand why it's so slow. For example, what does resolution mean? Does that mean fetching the pom.xml files from sonatype to figure out the dependency graph? Don't those HTTP requests normally go fast? Is Elide sort of like setting up an HTTP caching proxy between corp and sonatype?

sgammon 1y ago
> OK let's say I have an online store I wrote in Spring Framework. What does my before and after development workflow look like after adopting your plugin? Basically, you install this plugin, and it tells the `JavaCompile` tasks normally used by Gradle to `isFork = true` and use `elide javac -- ...` for the compile command. So, javac invocations travel over the CLI instead of through the Tooling API, which Gradle normally uses, and which is effectively running in Gradle's daemon VM, and thus is subject to JIT warmup. Through Elide, since it's a native binary, all that JIT warmup is skipped, and you are effectively choosing to balance more toward quick startup and wall-clock time (with many small calls) instead of waiting for JIT warmup to make the Gradle daemon fast with javac. Otherwise, it's a completely identical javac experience. Running `elide javac -help` produces identical help output. Identical inputs should produce identical outputs, and we build it at JDK 24 so it can support `--source/--target/--release X` and friends for anything older down to JDK 8. > For example, what does resolution mean? Does that mean fetching the pom.xml files from sonatype to figure out the dependency graph? It means resolving the graph from declared (direct) dependencies, downloading pom.xml metadata, downloading JARs, unpacking it all to disk, and providing a local `.m2` Maven-compliant root, sort of like Node does for `node_modules/`. Ours lives in `.dev/dependencies/m2` once you run `elide install`. Elide embeds Maven's resolver, so resolution semantics are identical to Maven's. We do some small optimizations to make fetching fast (i.e. initializing related classes at build time, that sort of thing), but honestly not much. Just building Maven's resolver like this yields a major gain, and not messing with it preserves expected behavior. Since Elide emits these deps in a Maven Local-style root, Gradle just finds them on disk when it needs them, so it doesn't need to engage its resolver or fetcher at all. > Don't those HTTP requests normally go fast? It is worth noting that Gradle seems confined to HTTP/1.1 and poor connection pooling even today, so it's not that hard to beat. > Is Elide sort of like setting up an HTTP caching proxy between corp and sonatype? We don't proxy or anything, this fetching still happens through normal Maven Central unless configured otherwise in your `elide.pkl` manifest. For now, deps are placed in the local project, but we want to move to a central cache and link like modern NPM installers do.
- sgammon 1y ago
  (Oh, if you are seeing how the plugin installs a Maven repository, that's just to ship our own plugin artifact and Gradle Catalog, for easy dependency use. maven.elide.dev doesn't proxy to central or anything like that.)

sgammon 1y ago

Volker Simonis over at Amazon did some very cool benchmarks showing the impact this can have (i.e. native-imaging javac): https://github.com/simonis/LeydenVsGraalNative https://github.com/simonis/LeydenVsGraalNative

alisonatwork 1y ago

Hypothetically, if you could daemonize javac, would JIT eventually kick in over multiple recompiles of the same code? The obvious use case for this would be IDEs, but I imagine it could work in CI too if you had some kind of persistent "compiler as a service" setup that outlived the runners. Not to detract from the cool work done here, just curious if this other approach has been tried too.

sgammon 1y ago
> Hypothetically, if you could daemonize javac, would JIT eventually kick in over multiple recompiles of the same code? This is actually how Gradle works by default; in fact, even if you pass `--no-daemon`, it will start a daemon, and just kill it after the build (lol). It's daemon-first, daemon-only, because of this exact issue. As I understand it, Gradle's daemon timeout is typically 10 minutes, but can be extended. We are guessing that this style rarely hits the 10k class threshold where JIT performance converges with native, especially since Gradle also supports incremental compilation, and that further impedes the progress toward a warm JIT. Gradle focuses hard on build caching and incremental compilation, and this is conceptually in contention with reaching a warm JIT, ironically. Native Image has JIT capabilities (just not as mature as Hotspot yet), and keeping the daemon alive would probably still yield wins. We haven't tried it yet and that's a good idea
- alisonatwork 1y ago
  I'm aware of the Gradle daemon, but wasn't sure if it only handled dependency resolution and other build orchestration tasks or if it also ran the compiler in the same JVM instance. Last time I worked somewhere using Gradle I think we forked the compiler anyway to ensure the project was built on exactly the same Java version regardless of what the Gradle environment was running in, so in that case there is definitely room for startup optimization. I do recall the Gradle daemon living much longer than 10 minutes, though. The docs say 3 hours is default, although if really trying to maximize the JIT advantage it perhaps would make sense to keep it alive as long as possible.
  - 1y ago

kristianp 1y ago

So elide is a tool to run {js|ts|py} [1]. How does it compile javac to native? [1] https://github.com/elide-dev/elide https://github.com/elide-dev/elide

sgammon 1y ago
In addition to being a runtime, Elide embeds `javac` and `kotlinc`. Here it is being used as a build toolchain, but it can also run those languages, through GraalVM/Truffle.
sgammon 1y ago
(In other news, I've added Kotlin to the list there, as {...|kt|kts}, so thank you for reporting this as well! We really need some docs updates and I'll make sure to clarify this stuff)
mdaniel 1y ago
What.is.happening.here. Are they committing node_modules or something? $ git clone https://github.com/elide-dev/elide.git Receiving objects: 100% (126086/126086), 643.85 MiB | 3.02 MiB/s, done.
- sgammon 1y ago
  There are some JARs we must commit to source because they are built with patches from upstream GraalVM components. That's probably the big weight there. We have an issue in our repo tracking those upstream PRs. Once merged, we won't need to do this anymore. We should probably publish them in our own Maven repo to avoid this kind of experience. Thanks for the push to take care of that cruft :P You can find them in `third_party/oracle`. You also don't need to build from source -- Elide ships as a binary for Linux amd64/macOS arm64. You are totally welcome to though, and if you encounter issues, hop in our discord and we'd be glad to help: https://elide.dev/discord https://elide.dev/discord

linksbro 1y ago

Would this result in the same .class that javac produces? I.e. at runtime is code compiled with this fundamentally different than code compiled with javac?

sgammon 1y ago
This results in identical .class bytecode that `javac` produces, yes, because it's literally just `javac`, but built as a native binary instead of a Java entrypoint. We build at JDK24 and support `--source/--target/--release` so you can build against earlier JVM targets. If you find any output differences between Elide and JDK24 (Oracle GraalVM), then we'd consider that a bug. Similarly, we accept identical compile flags and emit identical warnings/messages, as under the hood we are just using the same compiler APIs but natively.

re-thc 1y ago

Interesting idea. I wonder how this would compare to native-imaging Gradle or Maven itself.

sgammon 1y ago
Elide's resolver is just Maven's, and we use Maven's own components to read poms. Native-imaging Gradle itself is really challenging because Gradle relies so much on reflection, and really is architected to account for the JIT case (i.e. emphases on the daemon). I haven't found a way to do it yet so this plugin is the best alternative so far.

normie3000 1y ago

Is there an equivalent maven plugin? Also what's the licence for elide?

sgammon 1y ago
Not yet, but we are working on a Maven plugin :) if you join our Discord or file an issue, I can update you when its out. Elide is licensed under MIT https://github.com/elide-dev/elide https://github.com/elide-dev/elide

rjwalters 1y ago

Do you have benchmarks? How much of a difference does it make?

sgammon 1y ago
Benchmarking a toy case (hello world) shows a 20x performance difference; this is true for both kotlinc and javac, when benchmarked through hyperfine. YMMV, but benchmarks of different build styles show native converging with JIT at about 10k classes[1] So, if your project is 10k classes or less, you are looking at "up to" a 20x improvement in compile time vs. stock javac. On the dependency fetching side, we haven't benchmarked yet. It definitely feels like 100x+ though on a wall-clock basis. [1]: https://github.com/simonis/LeydenVsGraalNative https://github.com/simonis/LeydenVsGraalNative

Zardoz84 1y ago

interesting. I wonder how compares against mavend (mvnd , aka maven as a Daemon service) and his aggressive parallelization.

pjmlp 1y ago

Personally the solution to faster build times in Gradle, is to keep using Maven. I never touch Gradle unless there is no way around it, like Android. However, this looks like an interesting idea.

gerardnico 1y ago
Exactly, gradle is so slow that I ditch it into the ground. Just starting a blank project is so a bad experience. Nothing beat maven and a couple of shell script.
- pjmlp 1y ago
  I am convinced if they hadn't got Google's sponsorship, when Android decided to move into Gradle during Eclipse to InteliJ migration, we would be talking about Gradle as much as Grails is still discussed at local JUGs.
  - kasabali 1y ago
    Same, but also for Kotlin
    - pjmlp 1y ago
      Agreed.
Postosuchus 1y ago
This. And speed aside, Gradle embodies everything that is wrong with modern software development. A giant, opaque, idiosyncratic black box. I develop for Android (Java and Flutter) and it has become a sad pattern from Hell: Android Studio update mandates upgraded Gradle, which breaks previously the build in most weird ways, forcing one to trawl StackOverflow looking for proper incantations to do in the myriad of files it has created with the single purpose of building the damn app. Sometimes I wish, creating new build systems was outlawed some time after gmake or cmake...

lemming 1y ago

The underlying Elide tool looks amazing, and potentially solves all sorts of pain for me. Does the Kotlin compiler support plugins, e.g. serialisation? I can imagine they might be too reflective.

sgammon 1y ago
> The underlying Elide tool looks amazing Thank you! > Does the Kotlin compiler support plugins, e.g. serialization? We don't support Kotlin Serialization yet, but KotlinX is fully embedded and ready. You can reach for things like KotlinX Coroutines without installing a single JAR. Bring-and-use-your-own-plugins might be challenging, yeah, but we plan to at least build in the KotlinX plugins you would want by default (serialization included). So thank you for this note, it's helpful and I'll add a notch next to that feature :)