Java is too slow. Just because modern hardware allows for software to be very heavy doesn't mean that it should be acceptable for you as a developer to produce heavy software.
At the language/runtime level Java has been faster than anything else we have used on the Web with huge success (faster than PHP, Ruby/Rails, Python, Node, for example) even since 2000, and is as fast or faster than Go. It's also used in HFT - where ultimate speed means a lot.
Seriously, your argument sounds like the first year CS student argument of yore, where they hear that assembly is faster, and want to rewrite everything in assembly (fortunately today's first year CS students are more well informed).
TechEmpower benchmarks: https://www.techempower.com/benchmarks/#section=data-r19&hw=...
Language benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
And just because i found it pretty interesting, here's a summary of a study that not only measures memory consumption and execution time, but also how much energy certain languages required: https://jaxenter.com/energy-efficient-programming-languages-...
However, it's all besides the point because this tool takes Java (JVM) bytecode and translates it to WebAssembly, there's no JVM involved for end users at any point.
Sure... IntelliJ IDEA startup isn't instant. Atom's startup isn't instant. QT Creator's startup isn't instant. GIMP starts in a few seconds... etc.
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.
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.
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.
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...
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.
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)
Lambda instances run really well with JVMs(the whole COW memory architecture)... and even CLIs run well enough.
* Faster startup
* Better Lighthouse score
* Less code
See for yourself: https://renato.athaydes.com/posts/comparing-jvm-alternatives...
I do sometimes use Go for its contiguous memory layout and await JEP 169: Value Objects from Project Valhalla.
Part of the problem is that those also happen to be the frameworks that the vast majority of the community uses.
The Java zealots also tend to ignore all of the problems associated with AOT Java compilers and the fact that it will most likely be a few years before value objects are finalized and in a released version of Java. Even then, a ton of Java developers won't be able to use any features beyond Java 8 or 11 since a lot of companies don't want to give up the ability to easily use their libraries on Android.