Covariant overrides on the Buffer Hierachy

[Stuart Marks]

On 4/15/14 1:46 AM, Alan Bateman wrote:
> On 15/04/2014 09:05, Richard Warburton wrote:
>> The only issue that I'm aware of that is related to this kind of change is
>> the requirement to recompile all the classes in the hierarchy when making a
>> change [0]. If you don't do this its possible for an infinite recursion and
>> eventual stackoverflow to occur. Now as far as I can tell the
>> entire hierarchy of Buffer classes are all either package scoped classes,
>> or they are public classes with package scoped constructors. So I'm not
>> aware of a way to sub class them without the code being part of the JDK.
>> This would mean that the subclasses all need to be recompiled, satisfying
>> the safety criteria.
>>
> This is a long standing bug to look at this issue [1]. CharBuffer.subSequence
> was one case that was retrofitted in 7. As you note, buffers are not designed to
> be extended outside of the java.nio package so this should make a number of
> options possible.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-4774077

Hi Richard,

It looks to me like there are no obvious problems with changing the buffer 
subclasses to use covariant overrides. As Alan mentioned, one API was modified 
this way in 7, by Martin Buchholz. The discussion threads for this change are 
[2] and [3]. It looks like Martin considered additional covariant overrides, but 
ultimately backed off from this for a variety of incidental reasons; see [4]. 
There is a certain amount of work here above and beyond just changing the return 
types, but there don't appear to be any fundamental issues.

Ulf posted several links, but these seem mostly related to language change 
proposals related to implicit method invocation chaining. I don't think these 
proposals are active at the moment, so I'd suggest that you pursue a 
library-only change.

s'marks



[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-July/000596.html

[3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-August/000599.html

[4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-August/000612.html