Covariant overrides on the Buffer Hierachy
richard.warburton at gmail.com
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 . If you don't do this its possible for an infinite recursion
>>> 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 .
>> 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
>> options possible.
>>  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  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.
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.
More information about the core-libs-dev