Java has long been a favorite for building enterprise apps because of its stability and mature tools. But when it comes to serverless setups, Java often struggles with cold starts — those long delays when a function first runs. This can be a big problem for apps that need to be fast and responsive. Recently, developers found a way to fix this by combining GraalVM and Spring, making Java functions start almost instantly on AWS Lambda.

Why Java Cold Starts Are a Big Deal

The Java Virtual Machine (JVM) is designed to run high-performance, long-lived applications. It uses a technique called just-in-time (JIT) compilation, which analyzes code as it runs and makes it faster. That’s great for traditional apps, but in serverless, this causes delays. When a Lambda function starts cold, the JVM has to load classes, verify bytecode, and warm up the JIT compiler. This can take several seconds, which isn’t acceptable for real-time or latency-sensitive tasks.

AWS tried to solve this with Lambda SnapStart, which takes a snapshot of an initialized environment to reuse. But this isn’t perfect. It has limitations around state management and can risk serving stale data. So, developers looked for a better solution that could eliminate cold starts altogether at the application level.

GraalVM Native Image: Making Java Blazingly Fast

The breakthrough came with GraalVM Native Image. Instead of running Java bytecode on the JVM, this technology creates a native executable — a real machine code file that runs directly on the operating system. This is achieved through ahead-of-time (AOT) compilation. During build time, the native-image tool analyzes the app and figures out exactly what code is needed. It then strips away everything else, resulting in a tiny, fast-starting binary.

For building serverless functions, Spring Cloud Functions was a perfect match. It provides a simple way to write Java functions that don’t depend on the platform. The framework handles the translation of AWS events into Java objects, letting developers focus on business logic. When combined with GraalVM Native Image, these functions start in milliseconds rather than seconds.

Getting It Set Up: Maven and Environment Tips

To make this work, developers need to tweak their Maven configuration. The key dependency is the spring-cloud-function-adapter-aws, which connects Spring functions with AWS Lambda. They also include plugins like spring-boot-maven-plugin to package the app and native-maven-plugin from GraalVM for the AOT build.

Another important aspect is environment-specific settings. Spring often uses @Profile annotations to switch configs, but these don’t work well with native images because the static analysis occurs at build time. Instead, environment variables are used to provide configuration at runtime. For example, database endpoints can be set as environment variables, keeping the build simple and flexible.

Performance Gains That Speak for Themselves

After switching to a native image, the difference was dramatic. Traditional JVM functions took over 5.7 seconds to cold start. But with a native executable in a Zip archive, startup dropped to around 655 milliseconds — a nearly ninefold improvement. Once warmed up, the native functions were lightning-fast, with response times of around 20 milliseconds and much lower memory use.

Deploying as a container image also helped reduce cold start time, but it introduced some overhead due to the larger download size. Native images are small and efficient, making them ideal for serverless. For those who want even faster startup, removing the Spring framework and writing plain Java code as a native image can cut cold start times by another 30-40%, though it’s less convenient.

Building and Deploying Native Executables

Creating these native images requires a build environment similar to AWS Lambda’s. Since Lambda runs on Amazon Linux, the native build must happen in a Docker container based on Amazon Linux 2023. This ensures compatibility. The build process can take about four minutes, which is a small price for the performance boost during runtime.

Packaging is also different. Native images are standalone executables, so they can’t be deployed with the usual Java runtime. Instead, they are packaged using a custom runtime, which involves creating a simple bootstrap script. This setup ensures the native binary runs smoothly on Lambda, delivering the fast startup times developers crave.

By combining GraalVM Native Image and Spring Cloud Functions, Java developers are finally able to deliver serverless applications that start instantly and perform reliably. This approach unlocks the full potential of Java in serverless environments, making it a competitive choice once again for high-performance, event-driven systems.

Inspired by

• https://www.infoworld.com/article/4078803/taming-the-java-cold-start-beast-a-practical-guide-to-high-performance-serverless-with-graalvm-and-spring.html

Sources

• gmpg.org
• github.com
• spring.io
• podigee.com
• podigee.com