AWS Lambda Adopts Java 17
Written by Nikos Vaggalis   
Monday, 15 May 2023

AWS Lambda functions can now use all the new and useful language features as well as performance improvements introduced in Java 17 as part of the Amazon Corretto JDK implementation.

The Corretto 17 build was available from September 2022, but the support for it by Lambda functions wasn't until this April, 2023. Till now the highest Java version that Lambdas could run on was 11. Consider that Corretto 11 wasn't supported by Lambda until after 8 months of its release, thus Lambdas are a little slow to pick up the latest changes.

Corretto includes patches from Amazon that have proven useful in running their own services, but other than that it is at par with the rest of OpenJDK distros (TCK tested) and therefore can be used interchangeably. These patches include security fixes, performance enhancements, garbage collection scheduling, preventing out-of-memory situations, as well as improved monitoring, reporting, and thread management. What is important here is that Amazon upstreams its patches to OpenJDK, thus benefiting the whole OpenJDK league. This means the language features and performance gains that come with version 17 are now usable on Lambda too. These include:

Records
Records allow developers to define an immutable class with a set of named properties and methods to access those properties, making them perfect for event data
that Lambda heavily utilizes. Apart from simplifying code, making it easier to read and maintain, records can also provide better performance since they're immutable by default therefore Java’s runtime can optimize the memory allocation and garbage collection process.

Garbage collection
Java 17 makes available two new Java garbage collectors (GCs): Z Garbage Collector (ZGC). In the Java 17 managed runtime, Lambda continues to use the Serial GC as it does in Java 11. This is a low footprint GC well-suited for single processor machines, which is often the case when using Lambda functions, but you can change the default GC using the JAVA_TOOL_OPTIONS environment variable to one of the new alternatives if required.

Runtime JVM configuration changes
In the Java 17 runtime, the JVM flag for tiered compilation is now set to stop at level 1 by default. This is helpful in the majority of synchronous workloads because it can reduce startup latency by up to 60%.

That aside, the 17 runtime also supports AWS Lambda SnapStart, which is a service that solves the problem of function inisialitzation, as described in AWS Lambda Updated With SnapStart:

For a Lambda function to be initialized , it involves downloading the function’s code, starting the runtime and any external dependencies, and running the function’s initialization code. Ordinarily, for a Lambda function, this initialization happens every time your application scales up to create a new execution environment.

With SnapStart, the function’s initialization is done ahead of time when you publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and caches it for low-latency access. When your application starts up and scales to handle traffic, Lambda resumes new execution environments from the cached snapshot instead of initializing them from scratch, improving startup performance.

Generally upgrading to Java 17 is recommended because it is faster than 8 or 11. Framework developers want to pass on the performance improvements to customers, as well as wanting to use the improvements of the Java language in their code.

It's interesting to know that there was also an Amazon Corretto 18 release back in March 2022 which has been abolished in favor of 17 because 19 wasn't LTS, and now can't even be found on the official Corretto repo. Still you can find the official announcement here.

So in the end why go for Amazon's build of the JDK and not opt for one of the many chocies available nowdays?

  • OpenJDK builds by Oracle
  • Adoptium Eclipse Temurin
  • AdoptOpenJDK
  • Azul
  • BellSoft Liberica JDK
  • IBM Semeru Runtime
  • Amazon Corretto
  • Microsoft Build of OpenJDK
  • Alibaba Dragonwell
  • SapMachine
  • Red Hat OpenJDK
  • GraalVM

The main difference is that the various distros:

may contain backported fixes and enhancements we deem important to our customers and our internal users, which may have not yet been formally backported upstream

As such the Microsoft build of OpenJDK is recommended when running Java applications on Azure. Red Hat is the OpenJDK to choose if you're on Red Hat Enterprise Linux, while there's Liberica JDK which is the runtime of choice by VMware for Spring Boot and Spring Native. There's also the vastly popular Adoptium and Azul Zulu.

So given that guideline, stick to Corretto if you run Java applications on Amazon Linux 2 in AWS.

 

More Information

AWS Lambda now supports Java 17

Related Articles

Amazon Corretto 18 is now generally available

AWS Lambda Updated With SnapStart

 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Banner


52nd Mersenne Prime Found
27/10/2024

It has been nearly six years since the last Mersenne prime was discovered. Now, at last, we have Mersenne prime number 52 and it has 41,024,320 digits!



It Matters What Language AI Thinks In
23/10/2024

We are currently polarized in how we think about Large Language Models. Some say that they are just overgrown autocompletes and some say that they have captured some aspects of intelligence. How well  [ ... ]


More News

espbook

 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Monday, 15 May 2023 )