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