Covariant overrides on the Buffer Hierachy

Richard Warburton richard.warburton at
Sat Apr 19 08:09:09 UTC 2014


 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]
> 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.

Thanks for the feedback guys - its most appreciated and I'll take a look
through the detailed linked you provided.

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.

I had no intention in my original email to broaden the scope of this change
to include changing the type system itself! I was only really thinking
about a library level change, though I appreciate the links Ulf, thanks.


  Richard Warburton
  @RichardWarburto <>

More information about the core-libs-dev mailing list