What are the downsides of using GraalVM’s Native Image for Java apps?

Using Native Image has some notable downsides. For starters, it relies on the "closed world assumption," which means it can't dynamically load new class files at runtime. This affects how libraries that use reflection behave, since you'll need to explicitly define all reflective accesses. This can be a hassle, especially if your application uses a lot of libraries. Plus, while Native Image can be great, it doesn't always outperform traditional JVM performance, especially for long-running applications.

If your tech stack isn't geared towards native image support, it may not be worth the effort. I tried it for my Java/Scala game and while startup was faster, build times were significantly longer and dealing with dynamic features was a headache. Performance didn’t see much improvement either. FaaS might be an exception, as startup time is crucial there.

It really depends on your use case. For monolithic applications, JVM performance can still be superior, but for cloud-native microservices, Native Images can start faster and use less RAM, which is a win. If you’re not cloud-based, though, I’d think twice about making the switch.

Another critical point is that the free version of GraalVM only includes the Serial GC, which isn’t as efficient as modern alternatives. If you're developing performance-sensitive apps, this could hurt your performance.

Compiling to Native Image can be slow, and many Java libraries aren't yet compatible. On top of that, testing with native images can be tricky, and converting legacy applications can be a huge task for little benefit. All in all, the reduced memory usage and faster startup often don’t justify the extra fussy development time.