Different behavior between (F) and (Object & F)

[Remi Forax]

Hi Sergey,
the security issue is very real, given that we want to use lambda to 
implement things like
doPrivileged block, being able to serialize the lambda will leak all the 
captured values.

Rémi

On 11/08/2012 03:51 PM, Brian Goetz wrote:
>> Why just not to make all lambdas serializable and forget about that?
> Several reasons, including:
>    - Performance.  Because of our translation strategy, there's a
> performance cost to making all lambdas serializable:
>      - Extra static footprint in the capturing class
>      - Extra dynamic footprint under some translation schemes (since
> lambda would have to reify all the indy call information present at the
> capture site, including static and dynamic arguments)
>      - Some translation schemes can't handle it at all, and this would
> take these off the table, limiting the range of implementation choices
>
>    - Security.  Serializable lambdas effectively get desugared to public
> methods; this means snippets of logic that were implementation details
> of a computation become publicly addressable.  Making this true by
> default increases the attack surface by probably 5 orders of magnitude.
>
>> Allowing to mark lambda with ZAM will cause a huge usage of ZAM marking
>> interfaces in user's code. They get new feature -> they will use it in
>> all possible ways. But you may check marking with ZAM only by instanceof
>> that is not a good style.
> I am not sure it will show up that often.  The primary use case is
> 'defensive combinators', like Predicate.and(p1, p2), where you want the
> result to be serializable if the input predicates are.  But this is
> locked in library code.  The secondary use case is comparators passed to
> the constructor of TreeMap and the like.  But, we did some analysis of
> existing uses of serializable and concluded that the syntactic intrusion
> would not be very widespread -- but of course we could be wrong.
>
> The choice of syntax for serialization opt-in was one of the hardest
> decisions the EG had to make.  We considered at least a dozen
> candidates, all of which sucked so badly we gave up and had to come back
> to it -- twice.  In the end we chose (IMO) the least objectionable.
>