Abstract class as functional interface

This has been an important topic since the very inception of the Lambda project and has received a lot of thought. Brian Goetz, the chief Java Language architect, strongly supports the view of lambda as a function, not an object. Quote:

It is my belief that the best direction for evolving Java is to
encourage a more functional style of programming. The role of Lambda is
primarily to support the development and consumption of more
functional-like libraries

I am optimistic about Java’s future, but to move forward we sometimes
have to let go of some comfortable ideas. Lambdas-are-functions opens
doors. Lambdas-are-objects closes them. We prefer to see those doors
left open.

Here is a link to the quote’s source and here is Brian’s more recent post which reiterates the same philosophical points and reaffirms them with additional, more practical arguments:

Making the model simpler opens doors to all sorts of VM
optimizations. (Jettisoning identity is key here.) Functions are
values. Modeling them as objects makes them heavier, and more complex,
than they need to be.

Before throwing this use case under the bus, we did some corpus analysis
to found how often abstract class SAMs are used compared to interface
SAMs. We found that in that corpus, only 3% of the lambda candidate
inner class instances had abstract classes as their target. And most of
them were amenable to simple refactorings where you added a
constructor/factory that accepted a lambda that was interface-targeted.

Leave a Comment

tech