Hacker News Reader

Comment by pjmlp | Hacker News Reader

Since their introduction around 2000, AOT compilers have been special purpose.

There are several features in the platform for dynamic code generation that are very hard to make work in an AOT scenario.

View on HN

This is fine. However one thing that is not clear to me is why after telling for decades that startup time and memory usage does not matter, Java world is promoting Graal native so much.

Because Graal Community is free beer and plenty of developers don't want to pay for their tools, but enjoy being paid.

i don't understand your point; openjdk is free beer too. and graal-vm is an oracle project, as is hotspot?

And exactly for that reason, many are also euphoric about jaotc, which makes use of Graal anyway.

The goal is to remain competitive with Go. Java is still going to excel in cases when the benefits of JIT and superior GC have the opportunity to show themselves.

Graal native gives up the benefits of JIT for fast startup. It might be a useful tradeoff for some but it is not a universal solution.

As someone who's spent much of the last 20 years writing J2EE, Java EE and Jakarta EE projects, the answer is definitely that with containers and container orchestration, no one believes it anymore. Our new services are written in Go and have significantly shorter start-up times and smaller memory usage and it does matter (to us at least)!

I think this touches on some of the points that GraalVM/Mandrel and Quarkus are trying to address. No one wants those large J2EE/Spring monoliths anymore especially if they're deploying to K8s. Being able to quickly spin up replicas is where that short startup time and smaller memory usage comes into play. Scaling out vs scaling up (horizontal vs. vertical) is what Java devs have needed and it's being addressed with these new technologies.

Agreed ... but as noted elsewhere in this thread, your chance of getting a Wildfly (e.g.) application running in Quarkus and compiled to native via GraalVM is pretty small unless you've got a pretty standard CRUD application. We run into all sorts of problems with connections to anything that isn't a database including jobs that process JMS messages in an async fashion.

The funny thing is HotSpots startup time and memory usage are drastically lower on jdk 14 vs 8 [0].

I think the next step for Java will be more people shifting to using ZGC which automatically releases unused heap back to the OS where the current default (G1) doesn't.

[0] https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...

Reply on news.ycombinator.com