CODEWITHSUNDEEP
javalambdajava-8
Edwin Dalorzo
Edwin Dalorzo

Reputation: 78589

State of Lambda and Imperfections in Anonymous Classes

I was reading again Brian Goetz document on the State of Lambda where he details many of the reasons why Java needed lambda expressions.

In one of the paragraphs he wrote:

Given the increasing relevance of callbacks and other functional-style idioms, it is important that modeling code as data in Java be as lightweight as possible. In this respect, anonymous inner classes are imperfect for a number of reasons, primarily:

  1. Bulky syntax
  2. Confusion surrounding the meaning of names and this
  3. Inflexible class-loading and instance-creation semantics
  4. Inability to capture non-final local variables
  5. Inability to abstract over control flow

From this list of imperfections I believe I understand reasonably well the items (1), (2) and (4).

But I have no clue of what exactly the problems are in (3) and (5).

Can anybody out there provide any examples of how these two could be an issue when using anonymous classes?

Not all the projects I work on are yet on Java 8 and so I think it is important to understand these shortcomings and above all see clearly how things are better now with Java 8 lambdas. Also, since Brian was one of the leaders of the project lambda I thought it was worth my time to give it some thought to what he meant by this, it could lead me to an epiphany :-)

Upvotes: 3

Views: 172

Answers (2)

newacct
newacct

Reputation: 122449

I also want to add another thing about (3). "Instance-creation" might refer to the fact that when you create an instance of an anonymous class (new ...), just like when you create an instance of any class, you are guaranteed to get a new object. So the reference guaranteed to compare unequal != to the reference to any other object.

On the other hand, for lambdas, there is no guarantee that running a lambda expression twice will evaluate to two different objects. In particular, if the lambda doesn't capture any variables, then all instances of the lambda are functionally identical. In this case, it could just allocate one object statically and use it for the duration of the program. Allocating lots of objects is not cheap, so in the cases where it can avoid creating more objects, it makes the program more efficient.

Upvotes: 2

dkatzel
dkatzel

Reputation: 31648

Well 5. Inability to abstract over control flow is easy.

Lambda's are great to iterate over all the elements in a collection.

aCollection.forEach( myLambda)

The old way you would have to use for loops or Iterators or something similar.

for( ....){
   //same code as what's in the lambda
}

This is called internal iteration. We have to tell the collection not only what do do with each element in the collection BUT ALSO HOW TO GET EACH ELEMENT. This code iterates through all the objects in order sequentially. Sometimes that isn't the best for performance reasons.

Lambdas allow us to do external iteration. We only tell the collection what to do with each element. How each element is accessed and in what order is up to the Collection implementation to do it the most efficent way it can using internal implementation knowledge. It may even be parallel not sequential.

3. Inflexible class-loading and instance-creation semantics

Is a lower level issue with how Anonymous classes are loaded and instantiated. I will point you to this article: http://www.infoq.com/articles/Java-8-Lambdas-A-Peek-Under-the-Hood

But basically

  1. anonymous classes require making new class files for each one (MyClass$1 etc). This extra class has to be loaded. Lambdas don't make new class files and their byte code is created dynamically at runtime.
  2. Future versions of Java may be able to make Lambdas differently under the hood. By generating the lambda bytecode at runtime, future versions can safely change how Lambdas get created without breaking anything

Upvotes: 2

Related Questions