Covariant overrides on the Buffer Hierachy

[David M. Lloyd]

On 04/21/2014 04:51 PM, Richard Warburton wrote:
> Hi Peter,
>
>     I'm suggesting this alternative, because Buffer methods can stay
>     final in this case. This is more JIT-friendly. And, if I'm not
>     mistaken, client code compiled using JDK8 onto which this API change
>     was backported, would still run with JDK8 (or JDK7 when compiled
>     with -target 1.7) onto which the API change was not back-ported.
>
>
> Thanks for suggesting this alternative. I think there are a few
> downsides to this approach as well though.
>
> 1. Anyone with code referring to 'ByteBuffer' now gets rawtype generics
> errors.
> 2. Anyone with -Werror (like openjdk!) now fails to compile.
> 3. This is a more complex change than the one I was proposing and
> smaller, simpler, changes seem to be less risky.
> 4. Developers do genuinely get confused by generics. Not a reason not to
> use them ever but a good reason not to introduce them if the issue can
> be solved by an alternative approach.
>
> Happy to be corrected if I've misunderstood anything ;)

Um, do we *know* that there is a performance cost to covariantly 
overriding these methods?  There would seem to be enough information to 
keep them monomorphic, if the optimizer is smart enough to inline the 
bridge methods and the delegating override method.  The overridden 
methods in addition can be final, meaning that in the 99% case that 
you're invoking directly on the desired buffer type, it should be just 
as optimizable for the same reason that the original methods were 
optimizable.  The only potentially "slow" invocation path is if you call 
the method on a Buffer reference, and even then it seems like there's 
enough information to avoid slowness - and if not, then that seems like 
a HotSpot problem that is very solvable ("if all overrides of this 
method call super.xxx(), inline & eliminate them").

Is there a real, solid hypothesis that would demonstrate that any of 
this is not true?

-- 
- DML