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
