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

[Brian Goetz]

> 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.