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
