sgammon

> I work professionally in Python these days

Elide can run Python using GraalPy, and we want to do some similar toolchain stuff in that universe. We are working on an integration with uv. Thanks also for linking this Build Server Protocol thing -- this looks very cool, very relevant, and I don't think I've seen this yet.

> Seems the Scala guys have doubled down on the "compiler as a service" approach, presumably because their compile time story continues to be painful

I wonder if we could run the Scala compiler. Reflection is a challenge in native mode and iirc Scala is reflection heavy, but I have no idea, I've never used it myself. I'll look into this

> snapshot and restore the JVM state and turns out some people are experimenting with that too

There are many efforts in this area: CrAC, Leyden, the new JDK 24 AOT stuff, and pre-warmup stuff before that. These all do make a difference but Native Image takes AOT optimization to a whole other level and seems to perform better for quick-startup quick-shutdown cases[1].

Elide also runs JVM code via Truffle/Espresso, and we're going to need a regular JVM integration. On this side CrAC and so on will be useful to cut down on startup time

[1]: https://github.com/simonis/LeydenVsGraalNative

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.

(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)

> or if it also ran the compiler in the same JVM instance

Honestly, Gradle's toolchain resolution mechanisms have changed so much, it is a little hard to keep track. Good point

> The docs say 3 hours is default

Huh, I'm not sure where I got 10 minutes. I'll research some more about these assumptions, but even so, having used Gradle professionally and personally for many years (like you), I wonder how often I would have hit that threshold. I was mostly working in smaller projects and companies, though, so my experience could be different from the norm. Even assuming engineers hit that threshold, it would be toward the latter end of that window and only until the end of that window. An experience optimized for cold-start and non-reflection balances this approach, and is even build-cacheable with standard tools like sccache. There are still a lot of projects where JIT-based javac would be optimal

> perhaps would make sense to keep it alive as long as possible

It would for sure. I'm not sure why Gradle was never able to execute on Bazel's full vision for remote execution. Probably a hermeticity problem, considering the challenges they already seem to face with e.g. the configuration cache.

In any case, this is great feedback, thank you :)

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.

> 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

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

(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.)

> 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.

elide.dev | Multiple Roles | REMOTE OR OFFICE (US) | Full-time & Part-time | Kotlin + Rust

Elide, a new runtime built in Kotlin, and which runs JavaScript/TypeScript, Kotlin, Python, WASM, and soon Ruby.

https://elide.dev

https://github.com/elide-dev/elide

We are hiring for Kotlin and Rust. If you like things like Bun and are interested in the runtime space, reach out at sam@

Elide, a new polyglot runtime. https://elide.dev

Android Studio is only "free" to the user.

Kotlin

How does this compare to GraalPy? Why create something new when GraalPy can already build native programs?

Squandering great wealth requires great wealth in the first place

> You can't just assume someone has F-you money just because they worked for 20 years.

At Google? You can. Or they spent it all, in which case the point still applies.

Zoho? Like the email and calendar software? They are building a chip?

> Now, if only I could get devs to stop using lombok

One of the only remaining reasons I discard libraries without a further thought

It's 2025 and Guava supports JPMS now

One could easily generate the configurations via annotations, and I imagine Micronaut will do just that

A new runtime: Elide, which brings GraalVM and its benefits to new ecosystems. Runs Python, JavaScript, TypeScript, and Pkl.

https://elide.dev

Thanks, this is interesting. I'm also a big fan of your blog posts :)

Also, is there a Discord? Where's the community gathering? I'd like to try it :) looks neat.

By what metric is Python the most popular language on earth? I'm actually curious, genuinely asking. I thought JavaScript (Node) was king of newly written code, but perhaps that is outdated information.

Peak runtime performance is slightly better on JVM, yes. Native Image ships a JIT within your binary so it is not as different as one might think.

Yes. Native Image is covered by this license IIRC

It's not either/or. Compiling a Native Image binary gives you the JIT power of the JVM, but with faster warmup time.

Peak-peak performance is not as good as JVM in many cases, but how long does your process actually spend within that space? Native Image can be optimal for many cases

More of this configuration is automatic with every release

Well, it's also not true. But aside from that, plenty of software builds in its native environment. Cross-compiling is straight up hard for many toolchains.

> Compile to native makes sense only for very fast startup cases.

It also makes sense to reduce container size and vulnerability surface, and to reduce warmup time to peak JIT performance.

> Still I don't see any need for native compilation.

Sure, there isn't a "need," per se, just like there is not a "need" for JIT. This is how technology evolves. Things get better. Java's startup and time-to-peak performance are now comparable to native langs.