Hacker News Reader

Comment by Fiveplus | Hacker News Reader

Curious how many folks here experimented with the now depreciated Ahead-of-Time Compilation feature?

I did, the main issue is that jaotc doesn't do any pruning of the unused methods, so it generates too much assembly code. If i remember correctly, compiling just guava was to close to 1 gig.

GraalVM native image is far better, it "compiles" more slowly but the resulting executable is not too big.

I think that is by design due to reflection needs. Hard to prune unused code when it might be called reflectively at any time.

Which is why GraalVM requires you to explicitly mention what types should be available for reflection.

Yea, but that's impractical in a lot of cases where frameworks or large libraries are involved.

There are good frameworks that already work well with GraalVM native, including Quarkus and Micronaut. They avoid reflection altogether in most cases.

Only briefly tested it. I thought RH's Quarkus project made use of it, didn't it? What's the post-16 way of Java AOT compilation?

Graal is a separate project and jaotc did use that. I believe the reason for the “separation” is that the two projects have different priorities and didn’t develop at the same pace. I believe graal is still only at version 11.

But since Java, the language is highly backward compatible, one can trivially use Graal as is (without the preview features though)

I did experiment with it to improve the startup times of one of my applications (Java Swing). The gain was quite small, nearly not noticeable.

Reply on news.ycombinator.com