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

[Sergey Kuksenko]

I see.
The security is the answer which I need. Having the security issue Brian 
may not mention performance. :)


On 11/08/2012 08:09 PM, Remi Forax wrote:
> 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.
>>
>
>


-- 
Best regards,
Sergey Kuksenko