4 ms·

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

• JCWasmx86 6y ago
  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.
• _old_dude_ 6y ago
  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.
  • meddlepal 6y ago
    I think that is by design due to reflection needs. Hard to prune unused code when it might be called reflectively at any time.
    • brabel 6y ago
      Which is why GraalVM requires you to explicitly mention what types should be available for reflection.
      • meddlepal 6y ago
        Yea, but that's impractical in a lot of cases where frameworks or large libraries are involved.
        • brabel 6y ago
          There are good frameworks that already work well with GraalVM native, including Quarkus and Micronaut. They avoid reflection altogether in most cases.
• tannhaeuser 6y ago
  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?
  • kaba0 6y ago
    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)