covariant returns for CharBuffer.subSequence

[Martin Buchholz]

On Fri, Aug 1, 2008 at 1:39 AM, Alan Bateman <Alan.Bateman at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> We would like to have return types of methods be the most covariant
>> as is reasonable.  The only problem is compatibility.
>> For classes that cannot be subclassed by users,
>> changing covariant returns is almost 100% compatible.
>> (We all know that no change is 100.000000% compatible)
>>
>> The spec for CharBuffer.CharSequence appears to guarantee that
>> the returned object is itself a CharBuffer, so all we need to
>> change is the return type:
>>
>
> Right, buffers are not extensible (no public or protected constructors,
> etc.) so it does seem safe to take advantage of covariant returns.  There
> are a number of other "opportunities" in this package that Iris and I have
> chatted about for jdk7. In particular the Buffer flip/etc. methods come up
> quite often as the more specific return type would facilitate better method
> invocation chaining. Are you interested in doing those too? I ask because
> there are a couple of existing RFEs for this (4774077 is the main one)? If
> not, then we can create a specific bug for subSequence to let you get this
> done.

As often happens with me, this change is ever-expanding out of scope.
If we have consensus on the covariant returns for other Buffers,
I am willing to add these to the change.

> I see your String updates have a dependency on this. I've only glanced at it
> so far but I assume by moving the casts you can separate this work if
> required.

There is a dependency, but it is for performance only,
and it's not actually obvious it's a good idea,
since hotspot has gotten so much better at generating the
equivalent of the same code on its own.
Benchmarking required.

Martin