Serialization opt-in syntax (again)

[Remi Forax]

I've updated the corresponding bug:
http://java.net/jira/browse/JSR_335-1

Anyway, I'm am still not convinced that making a lambda Serializable add 
a cost that worth the pain of creating a new syntax.

Brian, do you have data about the supplementary cost of creating 
Serializable lambda ?

Rémi

On 09/28/2012 08:47 PM, Brian Goetz wrote:
> I put all the candidate syntaxes so far in the JIRA issue for this, 
> but a new one came to light this week that we kind of like.
>
> The problem is: let's say you have a SAM that is not serializable, but 
> you want the instance to be, such as in:
>
>   Runnable r = () -> { };
>
> The problem is that we really want to specify multiple interfaces for 
> the lambda, and as long as their intersection has only one abstract 
> method, that should be OK.
>
> So, how about using the space between the closing paren and the arrow:
>
>   Runnable r = () implements Serializable -> { ... }
>
> As a bonus, if we wanted to be explicit about all the implemented 
> interfaces, this easily extends to:
>
>   Object p = (String s) implements Predicate<String>, Serializable -> 
> { ... }
>
>
> This also extends nicely to inner class creation expressions. Right 
> now there is a limit of one named supertype.  But this could be extended:
>
>   Predicate<String> p = new Predicate<String>() implements 
> Serializable { ... }
>
> In this case, there is no single-method restriction; you could 
> implement Iterator and Runnable if you wanted:
>
>   new Iterator<T>() implements Runnable { ... }
>
> Note that none of this is serialization-specific; it is simply a way 
> of being explicit about multiple supertypes in contexts there this was 
> not previously allowed.
>