lambda syntax tutorial

[Kevin Bourrillion]

Agreed, adding an overload can sometimes be source-incompatible today, even
for a final class.  But in how many ways can this happen?  I'm only thinking
of one so far: if there could exist any list of actual parameter types that
would become ambiguous.  (If one of my signatures is a refinement of the
other, I should have no problem, since I should darn well be making sure the
two have equivalent behavior for the same inputs anyway).

This is pretty simple for me to watch out for in my API changes to my
released libraries.  And, I sometimes even have recourse to avoid it: for
example if I have only

  String join(Iterable<?> iterable);

and I want to add

  String join(Iterator<?> iterable);

I believe I can do this source-compatibly if I also add at the same time

  @Deprecated
  <T extends Object & Iterator<?> & Iterable<?>> String join(T iter) {
    return join((Iterable<?>) iter);
  }

(I'm planning to try exactly this in Guava.  Yes, I think it's as lame as
anyone that a class would implement both of those types.  Still, I like
knowing my changes are completely compatible.)

So, my question is: to what degree does the current proposal expand the set
of categories of source-incompatible API additions we can make?  And how
workaround-able are those?  For example, if Foo#bar has no contextual smarts
at all, then adding overload #2 of any method would *always* be
source-incompatible (which would be hideous!).  So how much intelligence
does it have?


P.S. fun trivia if you haven't heard it: my colleague once found a case
where adding overload C caused previous source references to overload A to
suddenly be compiled as references to overload B!  Ahh, fun times.
http://twofoos.org/content/java-type-system-holes/