Serialization opt-in syntax (again)

Brian Goetz brian.goetz at
Sun Oct 7 20:13:32 PDT 2012

> 1. Why I am *against* the *~>* syntax.
> Serialization is one of the more obscure features of Java. This makes it
> much more important that to make related syntax *self-explanatory* than
> for more ubiquitous features.
> "~>" is about the least self-explanatory syntax we could possibly have.

Totally agreed.  ~> is off the table.

> I'd say those *annotation-based options look most adequate to me*.
> (In the issue tracker there is some consensus of two more people about
> this, so I'm the third)

Yeah, its pretty attractive -- from the end-user perspective.  Except 
that after reviewing the options I just don't think this is going to be 
acceptable to us.  While it doesn't create much new syntax, it does 
cross some big lines we have spent eight years deliberately not crossing:
  - annotations don't affect language semantics
  - annotations don't affect bytecode generation
  - can't annotate expressions

While there are lots of people who want annotations to be something they 
are not, what they are is deliberate and I'm not looking for an 
opportunity to make that radical change.  (Also, the work of creating 
new targets like "lambda" for annotations is far more significant than 
some of the other approaches, and we're very short on time.)  What 
annotations are and aren't is already a confusing and contentious enough 
topic; this would further blur the boundaries in ways that might be 
convenient in the short term but problematic in the long term.

So I think we're going to have to take annotations mostly off the table, 

The approach I have come to prefer is a target-type approach, because 
this is most consistent with how lambda translation is driven now, and 
most consistent with how objects become serializable in other situations 
(by extending Serializable).  Of the target-type options, the 
intersection type cast seems the obvious choice because (a) the syntax 
already has precedent and (b) we may well want to expand the set of 
places where intersection types are allowed in the future, so it makes 
more sense to extend an existing concept that we might extend further 
anyway than create a new dead-end special-case concept.

There are some others (notably keyword) that are not outright 
unacceptable, but still seem less desirable than just using the 
(admittedly verbose) target type approach.

So, let's go back to where I set the bar earlier this week: aside from 
"I like XYZ better", are there any reasons why the intersection type 
cast should be unacceptable?

More information about the lambda-spec-experts mailing list