For example, the code for creating specific objects. It turns out that the parameter passed to our method is no longer a String, but a Function0 instead – which makes it possible to evaluate the expression lazily – as long as we don’t call it, the computation isn’t triggered – as simple as that. Long parameter lists may also be the byproduct of efforts to make classes more independent of each other.

Public static foo(scala.Function0) Ġ: getstatic #17 // Field LazyFoo$.MODULE$:LLazyFoo$ Ĥ: invokevirtual #19 // Method LazyFoo$.foo:(Lscala/Function0 )Ljava/lang/String If we try to javap reverse-engineer the generated *.class file, we’d see: Compiled from 'LazyFoo.scala' Now, if we wanted to make b computed lazily, we could leverage the call-by-name syntax and simply add two signs to the b‘s type declaration, and voilà: def foo(b: => String): String = b

Let’s create a simple foo method that accepts a String instance and returns it: def foo(b: String): String = b Whenever we want to lazily evaluate method parameters in Scala, we can do it the “call-by-name” way. In Java, the potential of lazy evaluation is quite neglected (actually, at the language level, it’s pretty much limited to the implementation of minimal evaluation) – advanced languages like Scala, for example, differentiate between call-by-value and call-by-name calls, or introduce dedicated keywords like lazy.Īlthough Java 8 brought an improvement on that field by providing the implementation of the Lazy Sequence concept (we all know it as ), today, we’ll skip that and focus on how the introduction of Lambda Expressions brought us a new lightweight method of leveraging delayed evaluation.

Kotlin by lazy with parameter