When introducing lambdas, why did they limit its usage to functional interface implementations?

[Monica Shiralkar]

Lambdas were introduced in Java 8. However its usage was kept limited to functional interface implementation unlike some other languages like Scala where there is no such limitation?

[Nam Ha Minh]

Could you give some examples which Lambda expressions should be used on non-functional interfaces?

[Monica Shiralkar]

Could you give some examples which Lambda expressions should be used on non-functional interfaces?

I am not talking about non functional interfaces. I am saying the usage of lambda expressions is limited to interfaces in Java 8.  

[Gerard Gauthier]

Monica Shiralkar wrote:

Could you give some examples which Lambda expressions should be used on non-functional interfaces?

I am not talking about non functional interfaces. I am saying the usage of lambda expressions is limited to interfaces in Java 8.  

First thing you have to understand... Java and Scala are two different languages which happen to run on the same environment. Scala, a language designed to embrace functional programming(functions), tends to rely on higher level functional abstractions while Java, a language designed around objects, embraces objects. Its really just a design choice.

[Dave Tolls]

Aren't Scala lambdas just based off FunctionX traits?
I'm not sure that's massively different to Java's various interfaces.

[Stephan van Hulst]

The internal structure of an object created by a lambda expression is incompatible with the internal structure of regular objects. Consider the following code:

  private Runnable anonymous() {
    return new Runnable() {
      public void run() {}
    };
  }
  
  private Runnable lambda() {
    return () -> {};
  }

Here's the decompiled bytecode:
 private java.lang.Runnable anonymous();    Code:       0: new           #2                  // class Example$1       3: dup       4: aload_0       5: invokespecial #3                  // Method Example$1."<init>":(LExample;)V       8: areturn  private java.lang.Runnable lambda();    Code:       0: invokedynamic #4,  0              // InvokeDynamic #0:run:()Ljava/lang/Runnable;       5: areturn  private static void lambda$lambda$0();    Code:       0: return
You can see that the anonymous() method creates an instance of the anonymous Example$1 class, and then calls invokespecial on it to call the constructor.

In the case of a lambda expression, the method just returns the result of an InvokeDynamic call. InvokeDynamic returns something similar to a MethodHandle that is linked to a CallSite that is wrapped around a method, in this case the static lambda$lambda$0() method. If you don't understand it, don't worry. It's pretty magic, and Java doesn't really have anything in the language that uses InvokeDynamic, other than lambda expressions and default methods.

So why can't InvokeDynamic be used for abstract classes? Well, an abstract class is more than just a method handle. An abstract class may have fields, initializers and constructors. These are run with the invokespecial call that you see in the bytecode for anonymous().

One could ask, why then can't we use a lambda expression for abstract classes that don't have fields, don't have initializers and don't have constructors? Well, if an abstract class has no fields, initializers or constructors, then what is the point of it? You can just use an interface.

[Monica Shiralkar]

Thanks. Why does this problem of internal structure incompatibility in java objects not arise in case of some other languages like Scala.

[Stephan van Hulst]

I propose you first write an example in Scala that uses a lambda expression to implement a type that is not an interface. Then we can discuss that example.

[Monica Shiralkar]

Below is such an example from Scala:

var increment = (x:Int) => x+1
    println(increment(10))

[Dave Tolls]

That example translates to a Function1 trait.
And traits are the closest thing in Scala to a Java interface.

[Monica Shiralkar]

I think it means that in whichever programming language there should be something (whether functional interface, function 1 trait or other), where only 1 method is involved with the functionality which we want to give to the lambda expression function. That it the reason it requires a functional interface or a function 1 trait etc.

[Stephan van Hulst]

Monica Shiralkar wrote:whichever programming language [...] where only 1 method is involved

No. Methods are exclusive to object oriented programming languages. Purely functional languages don't need functional interfaces because they have functions built into the language as first class citizens. In Haskell for instance, EVERYTHING is a function. In those languages you can view a constant as a function that has no parameters and returns itself.

That it the reason it requires a functional interface or a function 1 trait etc.

In Scala, it's not just the Function1 trait, it's ANY of the built-in scala.FunctionX traits, where X is an integer specifying the number of parameters that the function has.

[Monica Shiralkar]

That is a good explanation. Thanks.

[Monica Shiralkar]

After practicing a simple program using lambda, my understand is that there is a function which does something and may return something. Now the declaration of this function will be in some functional interface. Also,  there will be a method which which will be required to apply this function ( make use of this function in whichever way e. g applying it on some data). That's all we may need to know about using lambda expressions in Java.

[Stephan van Hulst]

Be careful how you use words that have a specific meaning.

You don't declare functions. You declare types, methods or variables.

You define a function either by writing a (possibly anonymous) class that implements a functional interface, or with a lambda expression.

BinaryOperator<Integer> multiply = (a, b) -> a * b;

In the above code, we declared a variable multiply which holds a reference to a function that is defined as a * b.

The parameter and return types of the function that is referenced by multiply are determined by the signature and return type of the apply() method that is declared in the BinaryOperator interface.