JVM vs. Native Java Compilation

Summary

There are many ways to optimize Java applications, see:
Optimization of Java Applications – CPU Usage, Memory Usage, Startup Time, Resource Efficiency

Depending on your use case, native compilation can be a potential optimization.

Comparisons

envite (2024)

GitHub - envite-consulting/showcase-graalvm

Red Hat (2022)

Source: https://www.redhat.com/en/resources/greener-java-applications-detail

Setup:

application: CRUD application that queries a database via a REST interface
load generator: wrk2
energy measurement: RAPL
machine: 2 CPUs, 16 cores per CPU
JVM Heap was allowed to use up to 12 GB memory

Results:

density test with a fixed workload (800 transactions/s): native is better because is requires less resources → less embodied carbon
capacity test with as much load as possible: application throughput is higher with JVM than native → less carbon per request

Red Hat Quarkus Lab Validation (2020)

https://www.redhat.com/cms/managed-files/mi-idc-quarkus-lab-validation-analyst-paper-f23914-202006-en.pdf

Sipek et al. (2020)

@Sipek.etal.2020.EnhancingPerformanceCloudbased

sipek.etal.2020.enhancingperformancecloudbased (pg. 5)

Quarkus running as a standalone native image produced by GraalVM runs 81.74% faster than the Spring Boot application with the same implementation. Quarkus implementation running on OpenJDK 13 runs 17.65% faster than the same Spring Boot application. Once again, Micronaut seems to outperform by 16.82% in terms of faster response times when running OpenJDK 13.

sipek.etal.2020.enhancingperformancecloudbased (comment) (pg. 5)

In other studies OpenJDK had advantages in comparison with native in terms of throughput. Unfortunately that was not measured here.

Conclusion

Use case for native:

low workload (throughput isn't the bottleneck)
resource-constrained or hold hardware (especially memory)
high re-deploy rate (applications never get warmed up before being spun down
serverless

Use case for JVM

high workload (you need lots of throughput)
long-lived processes (the rapid start of native doesn't save you much over the lifetime)
stable workload or very little elasticity in underlying orchestration

🔗 References

Writing Greener Java Applications by Holly Cummins

Quarkus in Action (Martin Štefanko and Jan Martiška, 2025)

Typically, in an environment where the startup time is not critical and the application is expected to be running for some time (classic microservices), the JAR can outperform the native executable. However, if the startup time is critical (serverless environments), then the native executable is the better choice.