4 Advantages of using Java with AWS Lambda

Serhat Can
4 min readNov 28, 2017

At OpsGenie, we have been using AWS Lambda with Java for nearly two years now. There is one disadvantage of using Java in AWS Lambda that everyone is aware of: cold starts. I’ll talk a little bit about this at the end of the blog post. Apart from that, we think Java has lots of advantages and should definitely be considered as a strong candidate for your Lambda functions.

Strong, well-tested libraries coupled with the experience of decades

Java has the experience of decades. Since 1995, both small organizations and big enterprises leverage Java not just because it is a well defined and supported language but also because of the great JVM (Java Virtual Machine). Although Java is old, it still keeps growing its community and is the most commonly used language in the industry (based on the TIOBE Programming Community Index). Because of its popularity, Java can also be seen as key for enterprises to move to Serverless environments.

A lot of Object-Oriented Programming (OOP) best practices are taught and applied using Java. Frameworks or libraries like Spring, JUnit, Mockito, and lots of others make the developers’ lives a lot easier by supporting testability and maintainability.

Better performance & consistency

Well, Java may have a problem with cold-starts, but it definitely has an advantage when it comes to consecutive executions. I will keep this part short as well, as Yan Cui, one of the favorite Serverless writers, already covered this topic in his blog post. As a summary, Java has better performance and consistency when you compare it with other languages for the same time window — although this may change based on what you do within your function.

Source: https://read.acloud.guru/comparing-aws-lambda-performance-when-using-node-js-java-c-or-python-281bef2c740f

Synchronous execution

This may be a bit personal but as someone who wrote with both Java and Node.js for AWS Lambda, dealing with callbacks is troublesome and async nature of Node.js does not feel right. If concurrency is what you need, then you can either deal with it in your application or write smaller functions. Ben Kehoe wrote a nice piece, you can check it out if you want to learn more about this:

Tooling support

This may not be accurate for Serverless specific tooling yet, but with the rise of Serverless, tooling for Java will be better. Proportional to the maturity of the language, Java has lots of great tooling support including IDEs (IntelliJ IDEA, Eclipse,…), dependency management & build tools (Maven, Gradle,…).

When it comes to monitoring, Serverless has its problems. A lot of new tools are emerging in this domain as well. Our new initiative, Thundra (coming soon for beta), for now focuses on Java. It gives you the ability to trace method calls in all layers to collect metrics like execution duration, and method arguments. Most importantly, it enables you to do it the right way, without messing up your code with logging statements. More information will be available soon, so don’t forget to sign up for early access.

The issue with cold start

Cold starts cause latency when a new container is created underneath. If your functions are granular, you will probably not going to experience this a lot. However, if your traffic is unpredictable or sparse and if you offer latency SLAs, this can cause you some trouble. Because of the nature of Java language, Java functions experience more latency than other languages. For now, there is no exact solution to this problem but there are ways to reduce them until then. With Java 9 supporting Oracle JDK’s nice features like AOT (Ahead of Time Compilation), hopefully coming soon to AWS Lambda, we hope that AWS will make use of it and maybe other creative solutions to reduce the cold start times for Java.

--

--