Demystifying Java Lambda Expressions

What is a Java lambda expression?

Java lambda expressions provide a concise way to encapsulate business logic. You can represent an anonymous block of code that can either be an expression or a series of statements, ultimately returning a result. The structure of a lambda expression is as follows:

(argument list) -> { body }

The syntax includes an argument list, an arrow token (->), and a body. I’ll walk you through some code examples in the next section which will make this clear.

This construct enables the creation of anonymous functions or methods without explicitly declared names. You can succinctly define behavior that can be passed as arguments to methods, similar to the concept of anonymous classes. Lambda expressions facilitate the expression of code in a compact and expressive manner, enhancing the readability and flexibility of Java code.

Java lambda illustrated with examples

Let’s look at some sample code to get more familiar with lambda expressions.

Task: Calculate Interest for a Loan

InterestCalculator loanInterestCalculator = (principal, rate, time) -> principal * rate * time / 100;

Task: Apply Discount to an Online Order

OrderDiscountProcessor discountProcessor = (totalAmount) -> totalAmount – (totalAmount * 0.1);

What you are seeing in the above examples is the following:

• They are anonymous: They don’t have an explicit name like a method would normally have. That’s good – less code to write and debug.
• They are functions: A lambda isn’t associated with a particular class (unlike a method is). But like a method, a lambda has a list of parameters, a body, a return type, and a possible list of exceptions that can be thrown.
• Passed around—A lambda expression can be passed as argument to a method or stored in a variable.
• Concise—You don’t need to write a lot of boilerplate like you do for Java anonymous classes.

You might come across the expression “passing code”. What does that mean?

When we talk about “passing code,” we are typically referring to the ability to provide a block of executable code (a function or behavior) as an argument to another piece of code. This is often used in the context of passing behavior to a method or function.

Why should you care about lambda expressions?

Before Java lambda expressions were introduced, passing code using anonymous classes was tedious and verbose. Lambdas fix this problem – you can pass code in a concise way.

An alternative to anonymous classes

Let’s first talk about anonymous classes.

In Java, you can create classes that don’t have a name. These are just like local classes (classes defined in a block) that you may already be familiar with. However, the key difference is that anonymous classes don’t have a name.

Anonymous classes enable you to declare and instantiate a class simultaneously, providing a way to create ad hoc implementations on the fly. This approach simplifies the code by combining class declaration and instantiation in a single step, making it convenient for scenarios where a temporary, unnamed class is needed.

The Oracle documentation makes it very clear:

Anonymous Classes, shows you how to implement a base class without giving it a name. Although this is often more concise than a named class, for classes with only one method, even an anonymous class seems a bit excessive and cumbersome. Lambda expressions let you express instances of single-method classes more compactly.

Later in this article, we’ll go through the specific benefits of Java lambda expressions. For now, here’s a list of things to keep in mind on “why Java lambdas”:

• Java lambdas are a replacement for anonymous classes. You don’t need to explicitly declare a method, as seen in traditional anonymous classes.
• They are shortcuts for writing short, simple methods. Java lambdas are great at making your code shorter and easier to understand.
• They work especially well with a programming style called functional programming, where you can do some cool things like passing functions as if they were regular data.
• Java lambdas seamlessly integrate with Java streams, enabling concise and expressive data processing. Stream pipelines can operate sequentially or in parallel. Lambdas allow for efficient parallel processing of collections, harnessing the full potential of multicore CPUs. This combination enhances performance by distributing computations, making Java development more scalable and responsive.

Anonymous classes also have a bunch of performance disadvantages

Anonymous classes also come with undesirable characteristics that can impact your application’s performance.

• Anonymous classes can prolong JVM start-up times due to the additional bytecode generation and class loading complexities they introduce.
• Increased JAR file size bloat due to generation of many class files. This hinders deployment efficiency and increases JAR download times.
• Anonymous classes can waste precious metaspace in the JVM, impacting memory usage and potentially leading to performance issues.
• Anonymous classes are also code cache inefficient, as their dynamic nature can result in less effective utilization of the code cache, negatively affecting runtime performance. Anonymous classes impact JVM start-up times

Lambda expressions solve many of the above performance benefits, which we’ll see below.

Benefits of Lambda Expressions illustrated with code examples

Benefit #1: Concise and better clarity => more developer productivity

Let’s understand with an example. You are writing an e-commerce application that needs to calculate the total price of products exceeding $200. You can do it the old way or the modern way.

double totalPrice = 0.0;

for (Product product : products) {

if (new PriceChecker() {

@Override

public boolean test(Product product) {

return product.getPrice() > 200.0;

}

}.test(product)) {

totalPrice += new PriceExtractor() {

@Override

public double apply(Product product) {

return product.getPrice();

}

}.apply(product);

}

}

interface PriceChecker {

boolean test(Product product);

}

interface PriceExtractor {

double apply(Product product);

}

double totalPrice = 0.0;

for (Product product : products) {

if (product.getPrice() > 200.0) {

totalPrice += product.getPrice();

}

}

See the brevity and conciseness in the side-by-side comparison above? Lambda expressions reduce boilerplate code, resulting in concise (and readable syntax). Developers can achieve the same functionality with fewer lines of code. The conciseness is achieved because Lambda expressions provide an expressive syntax that allows developers to focus on the core logic without unnecessary ceremony.

Benefit #2: Better readability =>  better collaboration across AppDev and SRE (and everyone else)

Lambda expressions, when used judiciously, enhance the structural clarity of code. Developers can easily discern the logic encapsulated within lambda expressions. This helps in aiding bug identification and resolution in the future.

As an example, the old-style code in the above example has more lines for conditional checks. As the business logic becomes more complex, this increased complexity may make the code harder to understand. This is true especially for developers who are new to the codebase or reviewing the code after some time.

Lambda expressions that are clear and comprehensible help in avoiding technical debt. Code that is easy to understand is less prone to introducing complexities, reducing the likelihood of accumulating technical debt in projects.

At the same time, developers should prioritize readability over brevity. If a Java lambda expression becomes too complex, it may hinder understanding rather than enhancing it.

Benefit #3: Encourages functional programming => flexible and modular code

The lambda expressions example shown gets the job done with less boilerplate code. Pass a lambda expression to filter products based on the condition product.getPrice() > 200.0, replacing the traditional for loop and explicit conditional statements.

Benefit #4: Improved start-up performance => faster user experience

Anonymous classes impact start-up times of JVMs. When you use anonymous classes, the compiler generates a new class file for each one. These files typically have names like ClassName$1 , where ClassName is the name of the class containing the anonymous class, followed by a dollar sign and a number.

Here’s why anonymous classes impact start-up times:

• Each class file must be loaded and verified before it can be used.
• Loading involves operations like disk I/O and decompressing the JAR file, which can be costly
• This process can be resource-intensive, impacting the startup performance of the application.

As a result, the more anonymous inner classes you have, the longer it may take for your application to start up, potentially leading to a less responsive user experience. Java lambda expressions result in lesser number of classes and therefore aid in faster JVM start up times.

Benefit #5: Lean JAR file sizes => faster download times, cost savings

The Java compiler generates multiple classes during compilation time. These classes contribute to JAR file bloat, leading to larger JAR file sizes. A JAR (Java Archive) file is a compressed file format that bundles Java class files, metadata, and resources into a single package. It allows developers to conveniently distribute and deploy Java applications or libraries, simplifying the management and sharing of Java code.

Bloated JAR files have several consequences:

• Quicker download times: Smaller JAR files download faster over networks. This is crucial especially in scenarios with limited bandwidth.
• Better deployment cycles: Compact JAR files are more efficient for deployment. They consume less disk space, facilitating quicker distribution and deployment processes, which is crucial in large-scale software distribution.
• Consumes less storage space: Especially important for resource-constrained devices.
• Cost Savings in bandwidth: Reduced JAR file sizes result in lower bandwidth consumption. This is true for cloud-based deployments where data transfer costs are a consideration.

Benefit #6: Memory efficient (metaspace) => optimized memory

Unlike PermGen, metaspace can dynamically adjust its size, avoiding common issues like OutOfMemoryErrors. Nevertheless, the instantiation of multiple anonymous classes can still contribute to increased metaspace usage.

The bottomline is that Lambda expressions take up less room in metaspace as compared to anonymous classes.

Benefit #7: Code cache efficient => stable applications

Since the code inside each anonymous class is compiled to machine code by the JVM, it would be stored inside a code cache. More code = more code cache bloat.

Again, lambda expressions are simply more code cache efficient when compared to anonymous classes.

Why are Java lambda expressions hard to instrument for tracing and monitoring?

APM and observability tools instrument Java applications by hooking into the JVM at the time of bytecode class loading. For observability instrumentation engineers, understanding the class loading  process is key.

Reason #1: Needs advanced instrumentation techniques

When it comes to “normal” Java classes vs Java lambda expressions, there’s a big difference in the class loading process.

In normal class loading, the bytecode is loaded via the “transform” method. However, for Java lambda expressions, the Java bytecode is loaded via the “bootstrap” method. This adds complexity to the instrumentation process.

The APM instrumentation engineer often must figure out how to use specialized techniques to instrument the bootstrap process.

The Lambda bootstrap method uses the InnerClassLambdaMetafactory to generate an inner class for the lambda at runtime. Observability tools must intercept this method and capture the method argument “classBytes” & modify it using advanced techniques such as ASM to check whether that bytecode matches with configured functional interface names.

Reason #2: Java lambda expressions bytecode vary from one JVM vendor to another

Each version of the JVM employs a different implementation of the bootstrap method. This also adds to the complexity of instrumenting the Java application.

Here are some examples of the additional complexity:

Java version 9 to 14

jdk.internal.misc.Unsafe. defineAnonymousClass(Class, byte[] , Object)

Java version 15 to 20

java.lang.invoke.MethodHandles$Lookup.defineHiddenClass(byte[], boolean, ClassOption…);

On Java version 21

java.lang.invoke.MethodHandles$Lookup.makeHiddenClassDefiner(String, byte[], Set, ClassFileDumper);

Beware blind spots in your APM and observability tools

What happens when your APM tool lacks Java lambda instrumentation and visibility, but your Java application indeed uses lambda expressions?

You could end up with incomplete traces.  If a Lambda makes external calls like JMS or third-party calls, missing instrumentation leads to gaps in distributed traces. This results in blindness to slowdowns in dependencies, creating black boxes that hinder root-cause analysis.

You might also see un-instrumented time blocks in code-level call graphs that indicate parts not covered by your observability tool.

As an SRE and IT Ops, select APM and observability tools with care

As an SRE, opt for tools that employ sophisticated instrumentation tailored for Java lambda expressions. One such example is eG Enterprise which gives you full-stack visibility into Java applications that use lambda expressions inside the code.

Unlike legacy monitoring tools that often necessitate code changes for debugging or troubleshooting data, modern tools, such as eG Enterprise, are Java Lambda Expression-aware. In my recent article on monitoring Java Lambda Expressions, I highlighted the challenge: many SRE and IT Ops tools lack diagnostic capabilities for this powerful code construct.

All this means that legacy monitoring tools often require changes to code or the way code is built to be made to obtain debug or troubleshooting data. And of course, for the SRE or IT Ops team this isn’t SREs are often simply handed third-party apps or apps developed by a siloed AppDev teams. Changing application code in order to gain observability insight is not feasible in many cases. Automatic observability tools such as eG Enterprise solve this problem out of the box.

It’s essential for SRE and IT Ops teams to prioritize tools that understand and support modern code constructs to simplify troubleshooting in contemporary applications. For further details and insights, visit Is your Java Observability tool Lambda Expressions aware?.

Ignoring this consideration could lead to significant challenges in effectively monitoring and troubleshooting modern applications, particularly those leveraging Java Lambda Expressions.

What’s the takeaway for SREs and IT Ops teams?

I’ve posted some of this information on LinkedIn and discussed how SREs are often too abstracted away from language features which have an impact on performance. By the time SREs get to know about it, it’s usually too late in the game. One SRE commented:

“How do you go about discussing this with the dev team, considering that SREs are not directly responsible for the application design and code development? Isn’t this more of a task for performance engineers”

As an SRE, having the tools to swim upstream (or shift-left) and influence AppDev teams to use performance efficient language features would be utopia. With eG Enterprise you will at least have the tools to troubleshoot efficiently and prove when the responsibility is in the AppDev team’s court.

However, it will also give a few SREs (perhaps those with previous coding experience or in less siloed organizations) the tools to open a collaborative conversation, perhaps along the lines:

“Hey folks, we saw that our Permgen and codecache is seeing some inefficiencies. In looking through the traces in observability, we are thinking we could do better with using the new Java language features like lambda. We can help pitch in with some before-vs-after load test benchmarks if you folks are game!”

The key takeaway for Site Reliability Engineers (SREs) and IT Ops teams is the critical importance of being attuned to language features, such as Java Lambdas, that can significantly impact performance.

Often, SREs may be abstracted from these nuances until it’s too late. Engaging with the development team becomes crucial, even if SREs aren’t directly responsible for application design and code development.

This collaboration ensures that performance considerations are addressed early in the development process. While performance engineers may lead specific efforts, fostering communication between SREs and developers allows for a proactive approach to identifying and resolving potential issues related to Java Lambdas. Understanding and discussing these language features can lead to more efficient, reliable, and performant applications in the long run.

For this collaboration to happen, SREs and IT Ops must choose APM and observability vendors that are modern Java ready.

Learn More

• Read my earlier article on guidance for SRE and IT Ops teams tasked with troubleshooting Java applications including Lambda Expressions, See: Is your Java Observability tool Lambda Expressions aware?
  
• Learn about distributed tracing technologies which can be used when deploying and monitoring Java applications, see: What is Distributed Tracing? – IT Glossary | eG Innovations
• For information on eG Enterprise’s support for Java stacks, see: Java Application Monitoring