Running a simple Java method in AWS Lambda with GraalVM (Part 1)

In recent years, cloud technologies have emerged as a critical component of today’s modern IT infrastructure. The wide array of services offered by multiple cloud providers meets most market demands. One such service, which has gained popularity, involves running event-driven code without the need to manage the underlying infrastructure. This article focuses on AWS Lambda.

With AWS Lambda, you can package a function into a zip or jar file and upload it directly to the AWS Lambda infrastructure. AWS Lambda executes the function as needed, such as when a REST call to an endpoint occurs or when a new message arrives at a queue. However, this flexibility has drawbacks that must be considered when deploying functions to AWS Lambda or any other provider.

A significant drawback is the “cold start” issue, where an AWS Lambda function must be loaded into memory the first time it is triggered. This can be a major disadvantage, especially if latency is a critical factor in your applications or workflows. Cold starts affect any deployed function, regardless of the programming language used.

To address this issue, AWS introduced solutions like “Provisioned Concurrency” and “Snap Start”, which reduce initialization delays by keeping functions in a ready state or by accelerating the startup process.

In Java, a common way to optimize the start time is by reducing the number of classes loaded into the classpath.

Nevertheless, Java compiles to bytecode, which is executed by the JVM; this process involves both interpretation and Just-In-Time (JIT) compilation, potentially adding overhead due to the intermediate steps.

For this reason, I have put together a simple Java method (with no other dependencies needed), which in this Part 1 will run in the standard JVM, while in Part 2, I’ll show how to run it with GraalVM on AWS Lambda.

Creating a Java method to run in the standard JVM

Let’s start by creating a simple Java function that will run in AWS Lambda to familiarize ourselves with the platform.

To work with AWS Lambda, we can use a CLI tool provided by Amazon or alternatively, the web interface. For simplicity, I will use the web interface, which requires no further configuration. However, please note that AWS is constantly updating the UI, so some forms and options might change or be renamed over time.

Now let’s create a package for the following method:

In this case, the package to be uploaded to AWS Lambda must be either a ZIP or a JAR file that contains our Java method. However, it can’t be just any ZIP or JAR; it must be a shaded one, meaning it must include all compiled code and all necessary dependencies.

I created this package using Maven and the Maven Shade Plugin:

Once the package is created, navigate to Lambda in your AWS Console.

On the new page, click on “Create function,” and a page named “Create function” will be displayed.

Select “Author from scratch,” then provide a function name (in my case, “MyFirstLambda”). Next, select the runtime (Java 21) and, lastly, choose the architecture (for this exercise, either architecture is fine). Finally, click on “Create function.”

After the lambda is created, a summary page will appear. It’s time to upload our shaded package we previously created with Maven. To do this, click on “Upload from” and then “.zip or .jar file.”

Once the package is uploaded, scroll to “Runtime settings” and click the edit button.

AWS Lambda does not automatically recognize what must be executed in our package, so we must edit the handler of the Lambda to point to our class and method. The handler format should be package.MyClass::myMethod.

Following the package, class, and method names, the handler’s name must be “learn.bernardoalvarez.MyFirstLambda::myLambdaMethod”.

Once the changes are saved, we are ready to test our Lambda function. As mentioned earlier, an AWS Lambda was triggered by an event. If we want to test our Lambda function, we must create an event. For that, click on the “Test” tab to create a new event.

Name the event, and in the “Event JSON” textbox, input a quoted string to pass to our Java method.

Finally, click “Test”

The Lambda function was executed correctly, as it displayed the expected string result. Note that the “init duration” was 431.76 ms. Running the same Lambda with the same input again returns no “init duration,” as the Lambda function still resides in memory, eliminating the need to start the method again.

What’s next?

In the upcoming Part 2, I’ll provide the necessary steps for setting up everything for our Java method to run on GraalVM. We’ll explore and tackle the complexities of the process to streamline the development process and compare how our Java method performs on the standard JVM versus GraalVM on AWS Lambda.

Words by Bernardo Alvarez, Senior Engineer in Altimetrik Poland