[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-lambda-dev
Subject:    When lambdas become objects
From:       zhong.j.yu () gmail ! com (Zhong Yu)
Date:       2012-11-28 15:18:42
Message-ID: CACuKZqFwkx=i1Y-KxhRHOGesJ4V0OPvLevFbHfgOFXSRmwBpcg () mail ! gmail ! com
[Download RAW message or body]

On Tue, Nov 27, 2012 at 10:34 PM, Michael Hixson
<michael.hixson at gmail.com> wrote:
> Thank you, that clears things up a lot.
> 
> > > Does every invocation of nonNull() return the same Predicate instance?
> > 
> > 
> > Implementations are permitted to do so, and ours (mostly) does.  But this is not \
> > guaranteed and you should not assume that it does.
> 
> When you say I shouldn't assume that it does, you mean that I
> shouldn't rely on that behavior for my program's correctness, right?
> I would like to be able to assume it performs this way because the
> code is cleaner than the  strategy used in the real
> j.u.f.Predicates.nonNull -- returning a casted static
> Predicate<Object>.
> 
> > > Does every invocation of isFunActivity() return a separate Predicate
> > > instance?  Or, would a given FunDetector instance always return the same
> > > Predicate instance?
> > 
> > 
> > Because isFun is an instance method, you have to capture the receiver variable \
> > 'this', so each capture is likely to result in a new object. (Note you could have \
> > written this both more compactly and more explicitly as "return this::isFun".)
> 
> Are there plans to eventually do some sort of instance-level caching &
> reuse of these lambdas, when the lambdas only capture 'this', either
> later in the JDK8 development cycle or else in a future version of
> Java?

If the caching increases object size, it's a big concern.

> I've found that kind of lambda to be extremely common in the code I
> ported.  I realize I could convert the inline lambdas to member
> variables to avoid the extra objects if I wanted to.  I probably
> wouldn't bother (because the inline versions tend to be more
> readable), but if you told me a near-future version of Java would have
> this 'this'-capturing-lambda-cache optimization then I wouldn't think
> about the issue at all.
> 
> > > Does every invocation of weirdSort(list, flag) cause the creation of
> > > exactly two Comparators?  Or does every comparison made by the outer
> > > Comparator lambda cause the creation of an additional Comparator (for the
> > > inner lambda)?
> > 
> > 
> > The latter.  The inner lambda is captured when the outer lambda is executed, and \
> > the inner lambda captures the 'flag' variable. 
> > You could rewrite it to not do so, by pulling the inner lambda out to the top \
> > level of weirdSort, and capturing that. 
> 
> Right, makes sense.
> 
> -Michael
> 


[prev in list] [next in list] [prev in thread] [next in thread]