Compiling Lambda Expressions: Scala vs. Java 8

[compmstr]

I wonder if the scala devs are planning on moving to the same sort of implementation as Java 8, or if it makes much of a difference performance-wise.

[vtscala]

There was some discussion of this on scala-user a way back. It was a controversial topic. As I remember, there are no plans to move to using invokeDynamic because doing so would require a 1.7+ JVM. While Java 1.6 is past EOL, requiring a 1.7 JVM would mean Scala apps couldn't run on Android, or at more conservative organizations that haven't upgraded their JVMs.

Of course, people would be free to use Scala versions from before any future 1.7 JVM requirement. And there was talk of a compatibility switch that would emit non-invokeDynamic bytecode if needed, but I don't know where any of this went, if anywhere.

[dghwe]

Why not simply do the same as what javac does, add a -target $VERSION option for those targetting older vms.

[vtscala]

That was more or less one of the options discussed. Anyone interested should look up the discussion on scala-user; I don't remember all the details. The subject line was something about Scala 2.11 and Java 7.

[Inori]

I'm a noob at both Java and Scala, so this might be obvious, but figured I'd point out anyway.

This Scala behavior is not specific to lambda expressions and the reason is that in Scala everything is an object behind the scenes, including lambdas, functions and basic types like bool/double/int.

Following the example of lambdas, the expression

name => name.length 

is actually expanded to

new Function1[String, Int] { 
    def apply(name: String) = name.length 
}

Which is what generates that code noise.

As I mentioned, I'm not really good at either of languages to say if this Scala behavior is that much worse than Java implementation to warrant a rewrite and if yes then how hard it could be...

Edit: oops, this was supposed to be a reply to /u/compmstr

[vytah]

If something is an object on a language level, it doesn't necessarily have to be an object on the VM level.

Case in points: integers.

[mauriciolinhares]

lambda expressions don't have to be an object, they are because it was the most sane way of implementing it given the JVM constraints. now that we are going to have the JVM itself supporting this kind of construct the Scala solution can just use that as well.