Java Lambda Expressions vs Anonymous Inner Classes

closuresjavalambdaprogramming-languages

There is a new hype with the long awaited lambda expressions in Java 8; every 3 day another article appears with them about how cool they are.

As far as I have understood a lambda expression is nothing more than an anonymous inner class with a single method (at least at the byte-code level). Besides this it comes with another nice feature – type inference but I believe the equivalent of this can be achieved with generics on some level (of course not in such a neat way as with lambda expressions).

Knowing this, are lambda expressions going to bring something more than just a syntactic sugaring in Java? Can I create more powerful and flexible classes or other object-oriented constructs with lambda expressions that aren't possible to be built with current language features?

Best Answer

tl;dr: while it's mostly syntactic sugar, that nicer syntax makes lots of things practical that used to end in endless, unreadable lines of braces and parentheses.

Well, it's actually the other way around as lambdas are much older than Java. Anonymous inner classes with a single method are (were) the closest Java came to lambdas. It's an approximation that was "good enough" for some time, but has a very nasty syntax.

On the surface, Java 8 lambdas seem to be not much more than syntactic sugar, but when you look below the surface, you see tons of interesting abstractions. For example the JVM spec treats a lambda quite differently from a "true" object, and while you can handle them as if they where objects, the JVM is not required to implement them as such.

But while all that technical trickery is interesting and relevant (since it allows future optimizations in the JVM!), the real benefit is "just" the syntactic sugar part.

What's easier to read:

myCollection.map(new Mapper<String,String>() {
  public String map(String input) {
    return new StringBuilder(input).reverse().toString();
  }
});

or:

myCollection.map(element -> new StringBuilder(element).reverse().toString());

or (using a method handle instead of a lambda):

myCollection.map(String::toUpperCase);

The fact that you can finally express in a concise way which would previously be 5 lines of code (of which 3 are utterly boring) brings a real change of what is practical (but not of what is possible, granted).

Related Solutions

Scala vs Java – Performance Comparison

There's one thing that you can do concisely and efficiently in Java that you can't in Scala: enumerations. For everything else, even for constructs that are slow in Scala's library, you can get efficient versions working in Scala.

So, for the most part, you don't need to add Java to your code. Even for code that uses enumeration in Java, there's often a solution in Scala that is adequate or good -- I place the exception on enumerations that have extra methods and whose int constant values are used.

As for what to watch out for, here are some things.

If you use the enrich my library pattern, always convert to a class. For example:

// WRONG -- the implementation uses reflection when calling "isWord"
implicit def toIsWord(s: String) = new { def isWord = s matches "[A-Za-z]+" }

// RIGHT
class IsWord(s: String) { def isWord = s matches "[A-Za-z]+" }
implicit def toIsWord(s: String): IsWord = new IsWord(s)

Be wary of collection methods -- because they are polymorphic for the most part, JVM does not optimize them. You need not avoid them, but pay attention to it on critical sections. Be aware that for in Scala is implemented through method calls and anonymous classes.
If using a Java class, such as String, Array or AnyVal classes that correspond to Java primitives, prefer the methods provided by Java when alternatives exist. For example, use length on String and Array instead of size.
Avoid careless use of implicit conversions, as you can find yourself using conversions by mistake instead of by design.
Extend classes instead of traits. For example, if you are extending Function1, extend AbstractFunction1 instead.
Use -optimise and specialization to get most of Scala.
Understand what is happening: javap is your friend, and so are a bunch of Scala flags that show what's going on.
Scala idioms are designed to improve correctness and make the code more concise and maintainable. They are not designed for speed, so if you need to use null instead of Option in a critical path, do so! There's a reason why Scala is multi-paradigm.
Remember that the true measure of performance is running code. See this question for an example of what may happen if you ignore that rule.

Java – Design pattern for object conversion (java)

The Translator Pattern is what you're asking for.

But I suspect what you're looking for is a framework, more than a pattern. I believe Dozer is popular in the Java world.

Best Answer

Related Solutions

Scala vs Java – Performance Comparison

Java – Design pattern for object conversion (java)

Related Topic