[skjfdoslifjeifj]

The free AOT compilers have atrocious compile times (far, far worse than even Rust or Scala) and don't support all of the features so library support is extremely fragile. A lot of extremely popular Java libraries make extensive use of runtime reflection and none of the AOT compilers handle it well without a lot of extremely error prone manual configuration.

I actually like Java and the JVM but if AOT compilation and efficient memory usage is what you want Java is definitely not the language to use.

[imtringued]

Yes, GraalVM requires a new sub ecosystem of libraries that are built with it's native image feature in mind. That means no more Spring, no more Hibernate and so on. Old codebases will not benefit and new code base require abandoning your existing Java expertise.

[skjfdoslifjeifj]

I agree. My main issue is with the Java zealots that come into the discussion and make it seem like anyone can just take their existing Java application and use it with an AOT compiler. The reality is that you will most likely have to make changes to your code, do a significant amount of configuration, and heavily modify or remove dependencies. Furthermore, you are isolating yourself from the huge Java community because very few people are using any of the existing AOT Java compilers.

They try to paint an extremely rosy picture of the current situation when the reality is that it's a very long way from the experience you get in Rust, Go, D, C, C++, Haskell, Ocaml or any of the languages where AOT is considered the default.

[sitkack]

> main issue is with the Java zealots

Any sufficiently large population will have someone who will literally say anything. And the common outrage trope on the internet is to rage against a straw man.

Now I haven't used GraalVM in production, but in having played around with it and doing new code from scratch, I found AOT compilation to be really good.

I think the change will come faster than you think.

You can build your leaf, domain level code into a native shared lib and still use the reflective code at the top level to compose the application.

https://www.graalvm.org/reference-manual/native-image/#build...

If Java gets CTFE (compile time function evaluation), constexpr for C++ folks, much of the need for runtime reflection would disappear.

There is no reason that JITed reflective code (along with VM) can't be combined AOT code in the same program. You can already do this in Graal via front ends for llvm-ir and wasm.

As it is now, you can already mix Rust, C, C++ trivially with bytecode via LLVM ir. And for languages that compile to Wasm, GraalVM has a front end for that as well.

https://www.graalvm.org/reference-manual/wasm/#embedding-web...

[kitd]

If Java gets CTFE (compile time function evaluation), constexpr for C++ folks, much of the need for runtime reflection would disappear.

Just to remind people that Quarkus has a "pre-compile" stage that allows code to wire itself up using reflection, annotations, config properties, etc, before the full compile. This makes start-up times much faster.

[pjmlp]

Thanks for the compliment, I deliver software solutions in Java, C#, JavaScript, TypeScript, Swift, Objective-C, C++.

[BoyRobot777]

> no more Hibernate and so on

Quarkus, Redhat's, native first frameworks works fine with Hibernate and GraalVM. One of contributors gave a [talk](https://www.youtube.com/watch?v=za5CSBX-UME&feature=youtu.be)

[pjmlp]

They work perfectly fine with JIT caches.

Plus not everyone is fan of Spring and Hirbenate.

The first I used only once in 20 years of Java projects, the second is the first to go away when I get called to optimise database performance in Java applications.

[pjmlp]

Hence JIT caches.