Will performance be the downfall for Java 8 and Project Lambda?

Everyone has been anxiously awaiting Java 8 and Project Lambda that comes with it. But has the excitement blinding the Java community to the potential problems that might emerge when developers start using Lambdas en masse?

What no one is saying about Lambda

What's new for Java in 2014? According to Java performance expert Kirk Pepperdine, the elephant in the room is how developers are going to deal with Lambda. Everyone's happy to natter on about how revolutionary and exciting Lambda is. But they seem to be sidestepping any discussion of potential challenges. Why?

  1. Some probably haven't thought deeply enough about the ramifications of such a substantial change in Java coding to realize that there will be significant obstacles. They see shiny new toys and hail the dawn of a new era.
  2. Others have a queasy feeling that things may get messy; but they don't know how to articulate what they think might happen. It feels safest not to say anything right now.
  3. A few experienced souls know full well what lies ahead. They just don't want to be labeled party poopers—although they will be the first on the bandwagon to heap criticism on Lambda and garner points for expertise on the topic when shortcomings become glaringly apparent.

In contrast, Pepperdine isn't afraid to point out that Lambda is wearing no clothes. He's not a hater; he just doesn't mince words when it comes to calling it like he sees it.

The performance on this stuff sucks at the moment...The standard Java imperative style performs much better.

Kirk Pepperdine, Java Champion

Not enough, too late?

The sad thing for Kirk is that he really wants Lambda to be amazing – especially the interfaces. "From my perspective, this kind of feature is something that I really missed from the beginning. Being able to construct and execute code blocks on the fly is a brilliant win. I just don't think the Lambdas actually achieve that in this case." He says the idea sounds great in theory, but the reality is a toolset with questionable usefulness. To be relevant, the new tools have to be easy to use in the environment where they will actually be used—not in contrived "examples" that look good in a presentation.

One of the most critical real world factors will always be performance. Unfortunately, this is not yet an area where Lambda shines. "The performance on this stuff sucks at the moment. I've done some little sample stuff, and the standard Java imperative style performs much better than the Lambda style does. That might be just a sign of maturity more than anything. They have to adjust the JITs and the optimizers to deal with this stuff. Until they get those things working nicely, we're stuck with something that doesn't perform as well as imperative code will."

This isn't the first time…

Kirk cautions that the introduction of Lambdas will result in a lot of the same issues that occurred when Generics were introduced. If we'd come out safely on the other side of that transition, he might be more hopeful about where we're headed now. But he says the developer community is still reeling. "I think we still have a Generic hangover. Generics has failed to do what it set out to do. I think what they were trying to do (without realizing it) was loosen the type system to make the code more useful. Yet the syntax is still grossly complex and people still have trouble wrapping their brains around it today."

Ironically, loosening the type system can result in such tightly coupled code that you can't change anything without rewriting everything. In some ways, Generics have made code more brittle rather than more useful. Ideally, you should be able to write things like sorting algorithms once, put them in a library, and reuse them in many different scenarios regardless of type. But Kirk confesses he finds himself using them mostly as a documentation feature or to gain access to conveniences in the language. Add Lambdas on top of Generics, and the code is going to get really difficult to read.

What's the solution?

Should we switch to alternative programming languages? Pepperdine says that's not called for, Java is still going to be our go-to language. But just telling people not to use Lambdas is not going to work either. They're here now and developers are going to be forced to use them. The trick will be figuring out where and how instead of just plugging them in wherever they might fit. There will be some tough decisions to make about how to mix imperative and functional style coding. It's not a sexy or satisfying answer, but it rings true.

Do you think Lambdas will be a boom or a bust? Let us know.

You can follow Kirk Pepperdine on Twitter: @javaperftuning

Dig Deeper on Big data architecture

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.