Serialization opt-in syntax (again)

Kevin Bourrillion kevinb at
Mon Oct 8 09:09:33 PDT 2012

I agree with all the points in your last flood of responses, Brian.

I'm ready to give up fighting against (Foo<Bar> & Serializable), and we
should move toward finalizing that decision, but also (separately?) still
evaluate whether it's worth offering the (& Serializable) shorthand as
well.  The shorthand has benefits similar to the Java 7 "diamond", though I
must concede the situation only comes up a tiny fraction as often.

On Mon, Oct 8, 2012 at 9:04 AM, Brian Goetz <brian.goetz at> wrote:

>  I see only two problems there:
>> * Allowing this kind of cast only on lambdas, which is ugly, but I'm OK
>> with it.
> I don't even think that this is actually the restriction.  Yes, it affects
> translation of lambdas, but would also work in cases where we currently
> already allow intersection types:
> <T extends X&Y> foo(T t) { ... }
> ...
> Object o = makeXAndY();
> foo((X&Y) o);
> In fact, the cast to X&Y fills in a current language hole, since there's
> no way today to say "I *know* this is an X&Y, trust me"  We just would not
> be able to call foo() without knowing the name of the class.
> Admittedly this is a rare situation and has not been a significant problem
> so far and is clearly not the goal of this effort.  But, I do believe it
> provides a good example why, in the absence of an "obviously good" ad-hoc
> syntax, we should lean harder on extending existing concepts rather than
> inventing yet new ones.

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the lambda-spec-experts mailing list