By Caroline Kvitka-Oracle on Oct 06, 2014
Stuart Marks, principal member of technical staff at Oracle, facilitated a fantastic discussion about lambda expressions during JavaOne. A panel of gurus offered their diverse perspectives and answered questions about lambdas submitted via Twitter. The panel included Maurice Naftalin, principal developer at Morningside Light; Brian Goetz, Java language architect at Oracle; Raoul-Gabriel Urma, a PhD candidate at the University of Cambridge; David Blevins, founder of Tomitribe; and Trisha Gee, Java engineer at MongoDB.
The panel opened with Urma, Naftalin, and Goetz discussing the inclusion of functional programming features, via lambdas and streams, into the Java language. The inclusion of these features allows Java developers access to these features without changing the nature of the language itself, they said.
Gee then described how MongoDB is moving toward the inclusion of lambdas and streams without losing compatibility with earlier versions of Java. This can be accomplished, she said, by exposing single-method interfaces and stream-like APIs, which both allow and encourage those using the library to use these new features without requiring the library itself to be compiled against older versions of Java.
Later, the discussion turned to when it is and is not appropriate to use lambdas. The panelists discussed how passing blocks of code longer than a single line into a lambda expression can easily make the lambda expression difficult to read and maintain. Method references allow the use of lambdas in these situations without reducing code clarity.
Because the Stream API makes parallelism so easy to implement, there is a great concern that it will be overused. “The problem with parallelism is that it’s too easy. You can just plunk it in there, and people see it as a magic incantation for extra speed,” said Gee. The panel quickly reached consensus that initially people will overuse it, and that there is no substitute for proper testing and benchmarking in a production-like environment. Goetz also pointed out that there is an extreme focus on performance, and reminded the audience that there is no reason to even think about performance tuning unless there is a business reason to do so. Frequently, the simple and easily understood code runs fast enough to meet the requirements, he said.
The conversation also ventured into the weaknesses in the current lambdas feature, mostly around exceptions. Checked exceptions do not play well with lambdas. One suggestion was simply to make the lambda expression throw an exception. Goetz explained that this was considered in the crafting of the spec. He said it is really a bad idea; it would require every lambda expression to be surrounded by a try-catch block, the catch statement must catch all exceptions, and the loss of precision should make us all “feel dirty.” Another potential problem is exception reporting; stack traces involving lambdas can be quite confusing to those not familiar with them.
The discussion closed with the panelists encouraging the audience to use Java 8—even if it is only in nonproduction situations, such as writing tests. They also pointed out that many Java developers will be learning a new programming paradigm and that they shouldn’t avoid using these features just because they don’t want to make mistakes.