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>
