Covariant overrides on the Buffer Hierachy
stuart.marks at oracle.com
Thu Apr 17 17:49:33 UTC 2014
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 . 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 . 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.
>  https://bugs.openjdk.java.net/browse/JDK-4774077
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
 and . It looks like Martin considered additional covariant overrides, but
ultimately backed off from this for a variety of incidental reasons; see .
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
More information about the core-libs-dev