The Dark Side Of Lambda Expressions in Java 8

Chen Harel

Mar. 27, 14 · Interview

Like (1)

Save

20.41K Views

blog_lambada_2

this post may not make me any new friends. oh well, i was never really popular at school anyway. but let’s get to the point. java 8’s biggest feature in terms of the language is undoubtedly lambda expressions. it’s been a flagship feature for functional languages such as scala and clojure for a few years, and now java has finally joined in.

the second biggest feature (depending of course on who you ask) is nashorn - the new jvm javascript engine that’s supposed to bring java up to par with other js engines such as v8 and its node.js container. but these new features have a dark side to them .

i’ll explain. the java platform is built out of two main components. the jre, which jit compiles and executes bytecode, and the jdk which contains dev tools and the javac source compiler. these two components are fairly (but not fully) decoupled, which is what enables folks to write their own jvm languages, with scala rising to prominence in the last few years. and therein lies some of the problem.

the jvm was built to be language agnostic in the sense that it can execute code written in any language, as long as it can be translated into bytecode. the bytecode specification itself is fully oo, and was designed to closely match the java language. that means that bytecode compiled from java source will pretty much resemble it structurally.

but the farther away you get from java - the more that distance grows. when you look at scala which is a functional language, the distance between the source code and the executed bytecode is pretty big. large amounts of synthetic classes, methods and variables are added by the compiler to get the jvm to execute the semantics and flow controls required by the language.

when you look at fully dynamic languages such as javascript , that distance becomes huge.

and now with java 8, this is beginning to creep into java as well.

so why should i care?

i wish this could be a theoretical discussion, that while interesting, has no practical implication on our everyday work. unfortunately it does, and in a very big way. with the push to add new elements into java, the distance between your code and the runtime grows, which means that what you’re writing and what you’re debugging will be two different things.

to see how let’s (re)visit the example below.

java 6 & 7

this is the traditional method by which we would iterate over a list of strings to map their lengths.

// simple check against empty strings
public static int check(string s) {
    if (s.equals("")) {
        throw new illegalargumentexception();
    }
    return s.length();
}

//map names to lengths

list lengths = new arraylist();

for (string name : arrays.aslist(args)) {
    lengths.add(check(name));
}

this will throw an exception if an empty string is passed. the stack trace will look like -

    at lmbdamain.check(lmbdamain.java:19)
    at lmbdamain.main(lmbdamain.java:34)

here we see a 1:1 correlation between the stack trace we see and the code we wrote, which makes debugging this call stack pretty straightforward. this is what most java devs are used to.

now let’s look at scala and java 8.

scala

let’s look at the same code in scala. here we’ve got two big changes. the first is the use of a lambda expression to map the lengths, and the second is that the iteration is carried out by the framework (i.e. internal iteration).

val lengths = names.map(name => check(name.length))

here we really start to notice the difference between how the code you wrote looks, and how the jvm (and you) will see it at run time. if an exception is thrown, the call stack is an order of magnitude longer , and much harder to understand.

at main$.check(main.scala:6)
at main$anonfun$1.apply(main.scala:12)
at main$anonfun$1.apply(main.scala:12)
at scala.collection.traversablelike$anonfun$map$1.apply(traversablelike.scala:244)
at scala.collection.traversablelike$anonfun$map$1.apply(traversablelike.scala:244)
at scala.collection.immutable.list.foreach(list.scala:318)
at scala.collection.traversablelike$class.map(traversablelike.scala:244)
at scala.collection.abstracttraversable.map(traversable.scala:105)
at main$delayedinit$body.apply(main.scala:12)
at scala.function0$class.apply$mcv$sp(function0.scala:40)
at scala.runtime.abstractfunction0.apply$mcv$sp(abstractfunction0.scala:12)
at scala.app$anonfun$main$1.apply(app.scala:71)
at scala.app$anonfun$main$1.apply(app.scala:71)
at scala.collection.immutable.list.foreach(list.scala:318)
at scala.collection.generic.traversableforwarder$class.foreach(traversableforwarder.scala:32)
at scala.app$class.main(app.scala:71)
at main$.main(main.scala:1)
at main.main(main.scala)

* remember, this example is very simple. with real-world nested lambdas and complex structures you’ll be looking at much longer synthetic call stacks, from which you’ll need to understand what happened.

this has long been an issue with scala, and one of the reasons we built the scala stackifier .

and now in java 8

up until now java developers were pretty immune to this. this will change as lambda expressions become an integral part of java. let’s look at the corresponding java 8 code, and the resulting call stack.

stream lengths = names.stream().map(name -> check(name));

at lmbdamain.check(lmbdamain.java:19)
at lmbdamain.lambda$0(lmbdamain.java:37)
at lmbdamain$lambda$1/821270929.apply(unknown source)
at java.util.stream.referencepipeline$3$1.accept(referencepipeline.java:193)
at java.util.spliterators$arrayspliterator.foreachremaining(spliterators.java:948)
at java.util.stream.abstractpipeline.copyinto(abstractpipeline.java:512)
at java.util.stream.abstractpipeline.wrapandcopyinto(abstractpipeline.java:502)
at java.util.stream.reduceops$reduceop.evaluatesequential(reduceops.java:708)
at java.util.stream.abstractpipeline.evaluate(abstractpipeline.java:234)
at java.util.stream.longpipeline.reduce(longpipeline.java:438)
at java.util.stream.longpipeline.sum(longpipeline.java:396)
at java.util.stream.referencepipeline.count(referencepipeline.java:526)
at lmbdamain.main(lmbdamain.java:39)

this is becoming pretty similar to scala. we’re paying the price for shorter, more concise code with more complex debugging, and longer synthetic call stacks.

the reason is that while javac has been extended to support lambda functions, the jvm still remains oblivious to them. this has been a design decision by the java folks in order to to keep the jvm operating at a lower-level, and without introducing new elements into its specification.

and while you can debate the merits of this decision, it means that as java developers the cost figuring out these call stacks when we get a ticket now sadly lies on our shoulders, whether we want to or not.

javascript in java 8

java 8 introduces a brand new javascript compiler. now we can finally integrate java + js in an efficient and straightforward manner. however, nowhere is the dissonance between the code we write and the code we debug bigger than here.

here’s the same function in nashorn -

scriptenginemanager manager = new scriptenginemanager();
scriptengine engine = manager.getenginebyname("nashorn");

string js = "var map = array.prototype.map \n";
js += "var a = map.call(names, function(name) { return java.type(\"lmbdamain\").check(name) }) \n";
js += "print(a)";
engine.eval(js);

in this case the bytecode code is dynamically generated at runtime using a nested tree of lambda expressions. there is very little correlation between our source code, and the resulting bytecode executed by the jvm. the call stack is now two orders of magnitude longer . in the poignant words of mr.t - i pity the fools who will need to debug the call stack you’ll be getting here.

questions, comments? let me know.

lmbdamain [java application]
lmbdamain at localhost:51287
thread [main] (suspended (breakpoint at line 16 in lmbdamain))
lmbdamain.wrap(string) line: 16
1525037790.invokestatic_l_i(object, object) line: not available
1150538133.invokespecial_ll_i(object, object, object) line: not available
538592647.invoke_ll_i(methodhandle, object[]) line: not available
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
2150540.interpret_i(methodhandle, object, object) line: not available
538592647.invoke_ll_i(methodhandle, object[]) line: not available
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
92150540.interpret_i(methodhandle, object, object) line: not available
38592647.invoke_ll_i(methodhandle, object[]) line: not available
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
731260860.interpret_l(methodhandle, object, object) line: not available
lambdaform$namedfunction.invoke_ll_l(methodhandle, object[]) line: 1108
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
2619171.interpret_l(methodhandle, object, object, object) line: not available
1597655940.invokespecial_llll_l(object, object, object, object, object) line: not available
lambdaform$namedfunction.invoke_llll_l(methodhandle, object[]) line: 1118
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
2619171.interpret_l(methodhandle, object, object, object) line: not available
1353530305.linktocallsite(object, object, object, object) line: not available
script$\^eval\_._l3(scriptfunction, object, object) line: 3
1596000437.invokestatic_lll_l(object, object, object, object) line: not available
1597655940.invokespecial_llll_l(object, object, object, object, object) line: not available
lambdaform$namedfunction.invoke_llll_l(methodhandle, object[]) line: 1118
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
484673893.interpret_l(methodhandle, object, object, object, object, object) line: not available
lambdaform$namedfunction.invoke_lllll_l(methodhandle, object[]) line: 1123
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
282496973.interpret_l(methodhandle, object, object, object, long, object) line: not available
93508253.invokespecial_lllljl_l(object, object, object, object, object, long, object) line: not available
1850777594.invoke_lllljl_l(methodhandle, object[]) line: not available
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
282496973.interpret_l(methodhandle, object, object, object, long, object) line: not available
293508253.invokespecial_lllljl_l(object, object, object, object, object, long, object) line: not available
1850777594.invoke_lllljl_l(methodhandle, object[]) line: not available
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
1840903588.interpret_l(methodhandle, object, object, object, object, long, object) line: not available
2063763486.reinvoke(object, object, object, object, object, long, object) line: not available
850777594.invoke_lllljl_l(methodhandle, object[]) line: not available
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
82496973.interpret_l(methodhandle, object, object, object, long, object) line: not available
220309324.invokeexact_mt(object, object, object, object, long, object, object) line: not available
nativearray$10.foreach(object, long) line: 1304
nativearray$10(iteratoraction).apply() line: 124
nativearray.map(object, object, object) line: 1315
1596000437.invokestatic_lll_l(object, object, object, object) line: not available
504858437.invokeexact_mt(object, object, object, object, object) line: not available
finalscriptfunctiondata(scriptfunctiondata).invoke(scriptfunction, object, object...) line: 522
scriptfunctionimpl(scriptfunction).invoke(object, object...) line: 207
scriptruntime.apply(scriptfunction, object, object...) line: 378
nativefunction.call(object, object...) line: 161
1076496284.invokestatic_ll_l(object, object, object) line: not available
1740189450.invokespecial_lll_l(object, object, object, object) line: not available
lambdaform$namedfunction.invoke_lll_l(methodhandle, object[]) line: 1113
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
2619171.interpret_l(methodhandle, object, object, object) line: not available
lambdaform$namedfunction.invoke_lll_l(methodhandle, object[]) line: 1113
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
323326911.interpret_l(methodhandle, object, object, object, object) line: not available
lambdaform$namedfunction.invoke_llll_l(methodhandle, object[]) line: 1118
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
323326911.interpret_l(methodhandle, object, object, object, object) line: not available
263793464.invokespecial_lllll_l(object, object, object, object, object, object) line: not available
lambdaform$namedfunction.invoke_lllll_l(methodhandle, object[]) line: 1123
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
1484673893.interpret_l(methodhandle, object, object, object, object, object) line: not available
587003819.invokespecial_llllll_l(object, object, object, object, object, object, object) line: not available
811301908.invoke_llllll_l(methodhandle, object[]) line: not available
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
484673893.interpret_l(methodhandle, object, object, object, object, object) line: not available
lambdaform$namedfunction.invoke_lllll_l(methodhandle, object[]) line: 1123
1076496284.invokestatic_ll_l(object, object, object) line: not available
lambdaform$namedfunction.invokewitharguments(object...) line: 1147
lambdaform.interpretname(lambdaform$name, object[]) line: 625
lambdaform.interpretwitharguments(object...) line: 604
323326911.interpret_l(methodhandle, object, object, object, object) line: not available
2129144075.linktocallsite(object, object, object, object, object) line: not available
script$\^eval\_.runscript(scriptfunction, object) line: 3
1076496284.invokestatic_ll_l(object, object, object) line: not available
1709804316.invokeexact_mt(object, object, object, object) line: not available
finalscriptfunctiondata(scriptfunctiondata).invoke(scriptfunction, object, object...) line: 498
scriptfunctionimpl(scriptfunction).invoke(object, object...) line: 207
scriptruntime.apply(scriptfunction, object, object...) line: 378
nashornscriptengine.evalimpl(scriptfunction, scriptcontext, scriptobject) line: 544
nashornscriptengine.evalimpl(scriptfunction, scriptcontext) line: 526
nashornscriptengine.evalimpl(source, scriptcontext) line: 522
nashornscriptengine.eval(string, scriptcontext) line: 193
nashornscriptengine(abstractscriptengine).eval(string) line: 264
lmbdamain.main(string[]) line: 44

Java (programming language) code style Scala (programming language)

Opinions expressed by DZone contributors are their own.

Comments

Trending

Trending

The Dark Side Of Lambda Expressions in Java 8

so why should i care?

java 6 & 7

scala

and now in java 8

javascript in java 8

Trending

Partner Resources