A peek past lambda

Rémi Forax forax at univ-mlv.fr
Thu Aug 18 14:16:00 PDT 2011

BTW, Maurizio recently push codes that enables the compiler
to compile without inner classes.

$ cd /tmp
$ hg clone http://hg.openjdk.java.net/lambda/lambda/langtools/
$ cd langtools
$ cd make
$ ant -Dboot.java.home=/usr/jdk/jdk1.7.0
$ cd ..
$ cp ~/Download/LambdaTest.java .
$ java -cp dist/lib/classes.jar com.sun.tools.javac.Main 
-XDlambdaToMethod=true -XDuseIndy=true LambdaTest.java
$ ls LambdaTest*
LambdaTest.class  LambdaTest.java
$ java -cp dist/lib/classes.jar:. LambdaTest

As you can see, no LambdaTest$1.class is generated :)

For the curious, the current implementation use a j.l.r.Proxy,
(so don't expect any performance now).


public class LambdaTest {
   public static void main(String[] args) {
     Runnable r = #{ System.out.println("foo"); };

On 08/18/2011 08:10 PM, Brian Goetz wrote:
> Along the lines that we've been discussing today, here's a peek at where
> we're heading.  We explored the road of "maybe lambdas should just be
> inner class instances, that would be really simple", but eventually came
> to the position of "functions are a better direction for the future of
> the language".
> This exploration played out in stages: first internally before the EG
> was formed, and then again when the EG discussed the issues.  The
> following is my position on the issue.  Hopefully this fills in some of
> the gaps between what the spec currently says and what we say about it.
> The issues that have been raised about whether lambdas are objects or
> not largely come down to philosophical questions like "what are lambdas
> really", "why will Java benefit from lambdas", and ultimately "how best
> to evolve the Java language and platform."
> Oracle's position is that Java must evolve -- carefully, of course -- in
> order to remain competitive.  This is, of course, a difficult balancing act.
> 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've offered examples such as
> filter-map-reduce to illustrate this direction.
> There is plenty of evidence in the ecosystem to support the hypothesis
> that, if given the tools to do so easily, object-oriented programmers
> are ready to embrace functional techniques (such as immutability) and
> work them into an object-oriented view of the world, and will write
> better, less error-prone code as a result.  Simply put, we believe the
> best thing we can do for Java developers is to give them a gentle push
> towards a more functional style of programming.  We're not going to turn
> Java into Haskell, nor even into Scala.  But the direction is clear.
> Lambda is the down-payment on this evolution, but it is far from the end
> of the story.  The rest of the story isn't written yet, but preserving
> our options are a key aspect of how we evaluate the decisions we make here.
> This is why I've been so dogged in my insistence that lambdas are not
> objects.  I believe the "lambdas are just objects" position, while very
> comfortable and tempting, slams the door on a number of potentially
> useful directions for language evolution.
> As a single example, let's take function types.  The lambda strawman
> offered at devoxx had function types.  I insisted we remove them, and
> this made me unpopular.  But my objection to function types was not that
> I don't like function types -- I love function types -- but that
> function types fought badly with an existing aspect of the Java type
> system, erasure.  Erased function types are the worst of both worlds.
> So we removed this from the design.
> But I am unwilling to say "Java never will have function types" (though
> I recognize that Java may never have function types.)  I believe that in
> order to get to function types, we have to first deal with erasure. That
> may, or may not be possible.  But in a world of reified structural
> types, function types start to make a lot more sense.
> The lambdas-are-objects view of the world conflicts with this possible
> future.  The lambdas-are-functions view of the world does not, and
> preserving this flexibility is one of the points in favor of not
> burdening lambdas with even the appearance of object-ness.
> You might think that the current design is tightly tied to an object box
> for lambdas -- SAM types -- making them effectively objects anyway.  But
> this has been carefully hidden from the surface area so as to allow us
> to consider 'naked' lambdas in the future, or consider other conversion
> contexts for lambdas, or integrate lambdas more tightly into control
> constructs.  We're not doing that now, and we don't even have a concrete
> plan for doing so, but the ability to possibly do that in the future is
> a critical part of the design.
> 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.

More information about the lambda-dev mailing list