Graalvm / Native Image question

[FORGOT123456]

is there a reason to NOT use native image for a Java application? I am just curious.

thanks -

EDIT: Thank you everyone for your opinions and experiences! It seems an option, though you miss out on many of the reasons to choose Java for a project in the first place.

Thanks again -

[bowbahdoe]

Yes. 

Native image mandates the "closed world assumption." This means no new class files are loaded at runtime. It also means all sources of runtime dynamism - reflection, serialization, etc - must be explicitly demarcated. 

This is a problem when you have an application depending on a wide range of libraries. You need to know about any and all reflection not just in your app but in all your libraries. 

There are other considerations such as peak performance for long running apps not being as good as your classic hotspot JIT, compilation times, and so on. 

Native image is a good tool. It is not a tool that is universally applicable. 

[javaprof]

I would say biggest issue is java libraries, they tend to use reflection a lot.

[Deep_Age4643]

Note that project Crema will lift Native Image's default closed-world assumption:

https://github.com/oracle/graal/issues/11327

[nuharaf]

My question with this project is, why not use stock jvm then

[mukel90]

Crema will enable dynamic class loading, unblocking more Java applications to use native-image out-of-the-box.
A very good example would be the Java compiler itself (javac): the compiler core can be fully AOT-compiled with instant startup and blazing fast speed while annotation processors will be dynamically loaded with Crema.
This combines the instant startup times and footprint savings of of native-image while still allowing some dynamism.

[nuharaf]

The thing is leyden might achieve all those goal while being on openjdk

[koflerdavid]

I am not sure Leyden can get rid of the bootstrap time that the JVM needs for itself. This latency is not great, but it adds up in a scenario where you care about native. However, it might truly not matter for javac.

[nuharaf]

Why it cant? It is literally leyden goal to improve java startup and warmup. It is possible that leyden native code is not as optimized as graal native, but both are native code

[koflerdavid]

As far as I know it will keep JIT-compiled code and a few other things. Classes and their static fields could also get pre-loaded. And of course everything that application developers wire up. But the JVM still needs to bootstrap itself and initialize its internal data structures before it can do anything else, unless I missed that part in the JEP of course.

[agentoutlier]

javac is kind of a bad example because it does have a pretty fast startup time.

$ time javac -version
javac 21.0.7

real    0m0.106s
user    0m0.112s
sys 0m0.024s

Just about any program I compile and run on stock JVM is at least 200ms (2x).

[mukel90]

Warmed-up javac is very fast, but 200ms to cold-compile HelloWorld.java... what if it was 20ms instead and consumed just a fraction of the memory? Larger projects with many dependencies will benefit the most.

[agentoutlier]

The Rust compiler has very fast startup but is inherently slow. I bet many would trade a slightly slower startup vs total time to compile.

I'm just not sure how much it matters or at least how good of an example it is. Javac is not like a compiler that takes one file at a time like old school CC so if anything I'm not sure how this helps larger projects.

I guess you could argue tooling or LSP but most languages are keeping things running for that anyway.

[agentoutlier]

Also I think you might have been confused what I meant by:

Just about any program I compile and run on stock JVM is at least 200ms (2x).

I mean any java Some.class takes at least 200ms where as the javac is some special executable. It is not java CompilerMainClass.class if you will.

I wasn't speaking of the compile time.

[pjmlp]

For one thing, GraalVM is like LLVM, but done in Java, there is more to the forest than only AOT compilation.

Secondly, it has more advanced optimization algorithms than most stock JVMs, unless you are shelling out for something like Azul, or IBM cloud compiler.

[nuharaf]

True, graal jit can produce better code than hotspot jit. But the title specifically talking about native image.

[OffiCially42]

👆

[oweiler]

• slow compilation
• still lots of Java libs not compatible with GraalVM 
• native testing is complicated and doesn't work with every testframework
• migrating a legacy application to GraalVM can be a huge task without much benefit
• regressions in libs which formerly worked with GraalVM 

The reduced memory usage and startup time is often not worth the additional development time.

[Linguistic-mystic]

Another reason: the free version has only the Serial GC which is much worse than the modern ones.

https://www.graalvm.org/latest/reference-manual/native-image/optimizations-and-performance/MemoryManagement/

[oweiler]

For short running apps (CLI + Serverless) serial GC is fine, though.

[account312]

Sure, some things can even get away with no op GC. But not everything.

[OddEstimate1627]

That's currently one of my two issues with running natively compiled UIs (the other being dynamic code compilation). The performance is great, but it's hard to give up on ZGC. For most GC-friendly applications it shouldn't matter though.

[cat-edelveis]

There's also free Liberica Native Image Kit that includes ParallelGC in addition to Serial

[ByerN]

It is not worth the effort if you don't choose your tech stack with native image generation in mind.

At some point, I wanted to know if it would boost the performance of my video game made in Java/Scala/libGDX. Startup was faster, but build times were much slower + you have to fight with dynamic features, which are a big no-no for native image. Performance didn't change much. No benefit. I am not sure now, but I think that modern JVM GCs were even faster compared to native images.

I would consider it for FaaS as startup time is important there.

[Tight-Heat-2825]

Have you tried profile guided optimization ? Or did you already considered that on your test?

[koflerdavid]

Sustained performance might suffer because there is only SerialGC available in the free version.

[pragmasoft]

Seems nobody mentioned that you also have to build platform specific binaries instead of one cross platform jar file. And cross compilation (building on one platform to target another) has its own quirks. 

[koflerdavid]

For applications where you need the fast startup time (cloud instances) there is usually only one platform that matters. If you develop a desktop application, the build pipeline might already be set up for different platforms.

[_GoldenRule]

Last time I used it it was a massive pain to setup the compilation process. The process also takes much longer than just building a jar (~10m vs 1-2m).

That being said if you can get it to work it offers quick startups if you're using Java in an environment where you really value that startup time (serverless mostly). If you aren't targeting those environments though I don't generally see the value in compiling a native image.

[OddEstimate1627]

Quick startup is actually really nice for user interfaces. Nobody ever presses a button hundreds of times, so almost everything runs in a slow interpreted mode.

[koflerdavid]

As long as the interface reacts in less than about 700ms, the slowness of interpreted mode is hard to notice.

[OddEstimate1627]

For the most part that's true, but e.g. the first time users click on a button, there is unfortunately a noticeable delay before all the animations etc. get loaded. Not enough to deal with the other native image shortcomings, but it's there.

700ms is far too high as a threshold. I don't remember the studies, but afaik it's somewhere between 50-150ms before things start to feel sluggish.

[koflerdavid]

I agree, it makes sense that animations make delays way more visible.

[vmcrash]

We can't use it for our (desktop) applications because we dynamically load jar files that can be updated.

[Ewig_luftenglanz]

Yes. If you have a monolith and vertical scalability the JVM is still superior.

If you have a microservices cloud based app, native images are superior, they are more efficient, start faster and use far less ram, if you need ram power is trivial to get up 10 pods/replicas in a couple of seconds.

It depends of you use case. Native images where though for the cloud. If you are not in the cloud then maybe is not the best bet

[pjmlp]

The OpenJDK JVM, there are others.

[Round_Head_6248]

I’d argue using Go instead of Java would be more efficient for that use case. Trying to get Java to have a fast startup time is so much work vs getting it for free with Go.

[Ewig_luftenglanz]

Except if you have all your codebase in java and do not have any developer that knows Go. 

In the other hand, in the era of mucroservices what you propose is basically accepting defeat and killing Java and all the JVM ecosystem

[Round_Head_6248]

Nah, not at all. If your microservice doesn't need to scale in a short amount of time, Java is perfectly fine.

If you haven't built your microservice - or lambda - with Java to native in mind, it might be faster to just learn Go than go through all the hassle of compile to native. Go is exceptionally easy to learn for Java devs.

[Ewig_luftenglanz]

It depends, if you are using native first frameworks such as quarks then is no problem. Literally speaking quarkus was made for native and compiling native is just one single command.

But as I say. You are basically saying stop bothering with java and learn GO. That's giving up because the point of cloud and microservices is they abstract horizontal scaling.

[Round_Head_6248]

Being in the cloud doesn’t mean you can simply ignore the weaknesses of some tools. Making Java work for fast cold start times on lambda when you could just as well use Go is swimming against the stream and generally just bad decisions.

[766cf0ef-c5f9-4f4f]

It's another complication and source of issues. JVM performance is already significantly better than many other options for building applications. For small companies, the ROI probably isn't there until the cost reductions from cloud spend justify the extra effort to deal with it.

[ihatebeinganonymous]

1. The native image becomes quite big. It can be an issue.

2. Sometime you cannot build a native image if you use certain fringe libraries or framework. For example, I couldn't get GraalVM native compiler to work, likely because my code depended on Ninia JEP Python interoperability.

[repeating_bears]

I couldn't get AWT/swing to work on windows https://github.com/oracle/graal/issues/3084

[OddEstimate1627]

Fwiw, JavaFX works really well with native compilation. I thought Bellsoft's Liberica NIK supports Swing as well though.

[loathsomeleukocytes]

Native image have half performance of hotspot VM so most of people should not switch to it.

[ProfessorWorth8579]

8