Covariant overrides on the Buffer Hierachy

Peter Levart peter.levart at gmail.com
Tue Apr 22 07:16:18 UTC 2014


On 04/21/2014 11: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.

Yeah, this would require all uses to replace ByteBuffer with 
ByteBuffer<?>. I guess this is a show-stopper.

> 3. This is a more complex change than the one I was proposing and 
> smaller, simpler, changes seem to be less risky.

If we can prove that relaxing Buffer final methods does not represent a 
performance regression, then by all means, it seems less risky.

Regards, Peter

> 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 ;)
>
> regards,
>
>   Richard Warburton
>
> http://insightfullogic.com
> @RichardWarburto <http://twitter.com/richardwarburto>




More information about the core-libs-dev mailing list