Lambda state and imperfections in anonymous classes
I was reading again Brian Goetz's doc on lambda state where he explains in detail the reasons why Java needed lambda expressions.
In one of the paragraphs, he wrote:
Given the increasing relevance of callbacks and other functional idiom styles, it is important that Java data modeling is as much as possible. In this regard, anonymous inner classes are imperfect for a number of reasons, most notably:
- Bulky syntax
- The confusion surrounding the meaning of the names and
this
- Inflexible class creation semantics and semantics
- Failure to commit non-final local variables
- Failure to abstract from control flow
From this list of shortcomings, I believe I understand items (1), (2) and (4) well.
But I have no idea what exactly the problems are in (3) and (5).
Can any of you provide any examples of how these two can be a problem when using anonymous classes?
Not all of the projects I'm working on are still in Java 8, so I think it's important to understand these shortcomings and above all to see clearly how best to work with Java 8 lambdas now. Also, since Brian was one of the leaders of the lambda project, I thought it was worth taking the time to think about what he meant, it might lead me to an epiphany :-)
source to share
Good 5. Inability to abstract over control flow
easy.
Lambda works great for all items in a collection.
aCollection.forEach (myLambda)
The old way you need to use for loops or iterators or something similar.
for( ....){
//same code as what in the lambda
}
This is called internal iteration. We have to tell the collection not only what to do with each item in the collection, BUT ALSO HOW TO GET EACH ITEM . This code is repeated through all objects sequentially. This is sometimes disadvantageous for performance reasons.
Lambdas allows us to do external iteration. We tell the collection what to do with each item. How each element is accessed and in what order the Collection is implemented to do so in the most efficient way that you can use the knowledge of the internal implementation. It may even be parallel rather than sequential.
3. Inflexible class-loading and instance-creation semantics
Is a lower level issue with how anonymous classes are loaded and instantiated. I'll point you to this article: http://www.infoq.com/articles/Java-8-Lambdas-A-Peek-Under-the-Hood
But mostly
- Anonymous classes require the creation of new class files for each one (MyClass $ 1, etc.). This additional class must be loaded. Lambdas does not create new class files, and their bytecode is generated dynamically at runtime.
- Future versions of Java may create Lambdas in different ways under the hood. By generating the lambda bytecode at runtime, future versions can safely change the way Lambdas are created without breaking anything.
source to share
I also want to add one more thing (3). "Instantiation" can refer to the fact that when you instantiate an anonymous class ( new ...
), as with instantiating any class, you are guaranteed to get a new object. Thus, the reference guaranteed to compare the unequal !=
with a reference to any other object.
On the other hand, there is no guarantee for lambdas that executing a lambda expression twice will evaluate to two different objects. In particular, if the lambda does not capture any variables, then all instances of the lambda are functionally identical. In this case, he can simply allocate one object statically and use it for the entire duration of the program. Allocating many objects is not cheap, so in cases where it can avoid creating more objects, it makes the program more efficient.
source to share