On Fri, Aug 1, 2008 at 1:39 AM, Alan Bateman <[EMAIL PROTECTED]> 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
