64 bit collections, and API migration in general (was Re: Migrating methods in Collections)

[Brian Goetz]

> 2. It seems irresponsible to spend so much effort on
> Collections without also somehow addressing 32bit size/index
> limitations. Yes?

I think that's really a separate question.  While everything said so far 
is Collection-specific, it's not really "so much effort on Collections" 
as much as "so much effort to ensure that legacy libraries can be 
compatibly anyfied", and that Collections is the poster child for that 
effort.  (If we can't migrate Collections, that's evidence that we're 
still lacking in linguistic tools for supporting the transition to 
anyfied generics.)

So I'll interpret your question as: "These are nice migration tools for 
migrating erased libraries to anyfied, but there are other migrations 
we'd like to perform on these aging libraries, please don't forget about 
them?"

The migration in question is whether we can compatibly migrate methods like:

     get(int index)
to
     get(long index)

For API migration, there is a 2x2 compatibility matrix: {source,binary} 
x {client,subclass}.  The hard quadrant of this is almost always "binary 
compatibility for subclasses"; the others can usually be handled by some 
combination of bridge methods, defaults, and compiler fu.

Essentially, the nasty case comes about when you have some combination 
of A extends B extends C where some of these have not been recompiled, 
and someone ends up overriding a bridge instead of the real method, and 
you can end up invoking the wrong method.  I'll provide more details 
soon, but let's come back to this under the more general topic of 
signature migration -- which we're going to need in order for Optional 
and friends to become values anyway.  OK?